Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit systems

2013-06-04 Thread Tobias Waldekranz
On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote: > B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote: > > In ktime_get_update_offsets, calculate the current time in the same > > way as in ktime_get. > > > > On 32-bit systems, the current time i

[PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit systems

2013-06-03 Thread Tobias Waldekranz
longer fit in 31-bits (2038-01-19 03:14:07 UTC). This will send hrtimer_interrupt into an infinite loop on some architectures (arm), or emit an oops on others(x86). Signed-off-by: Tobias Waldekranz --- kernel/time/timekeeping.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[PATCH] net: phy: add tracepoints

2018-08-16 Thread Tobias Waldekranz
Two tracepoints for now: * `phy_interrupt` Pretty self-explanatory. * `phy_state_change` Whenever the PHY's state machine is run, trace the old and the new state. Signed-off-by: Tobias Waldekranz --- drivers/net/phy/phy.c | 4 +++ include/trace/events/phy.h

[PATCH v2] net: phy: add tracepoints

2018-08-16 Thread Tobias Waldekranz
Two tracepoints for now: * `phy_interrupt` Pretty self-explanatory. * `phy_state_change` Whenever the PHY's state machine is run, trace the old and the new state. Signed-off-by: Tobias Waldekranz Acked-by: Steven Rostedt (VMware) --- v1 -> v2: * Actually include the enti

RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support

2021-02-10 Thread Tobias Waldekranz
On Wed, Feb 10, 2021 at 10:41, Mickey Rachamim wrote: >> Until that day arrives, are there any chances of Marvell opening up CPSS in >> the same way DSDT was re-licensed some years back? > The CPSS code is available to everyone on Marvell Extranet (Requires simple > registration process) Right,

Re: [PATCH net] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add

2021-01-30 Thread Tobias Waldekranz
On Sat, Jan 30, 2021 at 21:43, DENG Qingfang wrote: > Having multiple destination ports for a unicast address does not make > sense. > Make port_db_load_purge override existent unicast portvec instead of > adding a new port bit. Is this the layer we want to solve this problem at? What are the con

Re: [PATCH net] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add

2021-02-01 Thread Tobias Waldekranz
On Sun, Jan 31, 2021 at 09:13, DENG Qingfang wrote: > On Sun, Jan 31, 2021 at 8:39 AM Vladimir Oltean wrote: >> >> Tobias has a point in a way too, you should get used to adding the >> 'master static' flags to your bridge fdb commands, otherwise weird >> things like this could happen. The faulty

Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support

2021-02-08 Thread Tobias Waldekranz
On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote: > On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote: >> From: Serhiy Boiko >> >> The following features are supported: >> >> - LAG basic operations >> - create/delete LAG >> - add/remove a member to LAG >> - en

Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support

2021-02-09 Thread Tobias Waldekranz
On Mon, Feb 08, 2021 at 13:05, Jakub Kicinski wrote: > On Mon, 08 Feb 2021 20:54:29 +0100 Tobias Waldekranz wrote: >> On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote: >> > On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote: >> >> From: Serhiy Boiko >&

Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support

2021-02-09 Thread Tobias Waldekranz
On Mon, Feb 08, 2021 at 23:30, Andrew Lunn wrote: >> > I took a quick look at it, and what I found left me very puzzled. I hope >> > you do not mind me asking a generic question about the policy around >> > switchdev drivers. If someone published a driver using something similar >> > to the follow

RE: [EXT] Re: [PATCH net-next 5/7] net: marvell: prestera: add LAG support

2021-02-09 Thread Tobias Waldekranz
On Tue, Feb 09, 2021 at 20:31, Mickey Rachamim wrote: > Hi Andrew, Jakub, Tobias, > > On Tuesday, February 9, 2021 7:35 PM Jakub Kicinski wrote: >> Sounds like we have 3 people who don't like FW-heavy designs dominating the >> kernel - this conversation can only go one way. >> Marvell, Plvision

Re: [RFC PATCH v2 net-next 01/16] net: dsa: call dsa_port_bridge_join when joining a LAG that is already in a bridge

2021-03-22 Thread Tobias Waldekranz
idge port is handled in the next > patches. > > Signed-off-by: Vladimir Oltean > --- Reviewed-by: Tobias Waldekranz

Re: [RFC PATCH v2 net-next 02/16] net: dsa: pass extack to dsa_port_{bridge,lag}_join

2021-03-22 Thread Tobias Waldekranz
t; > Signed-off-by: Vladimir Oltean > --- Reviewed-by: Tobias Waldekranz

Re: [RFC PATCH v2 net-next 04/16] net: dsa: sync up with bridge port's STP state when joining

2021-03-22 Thread Tobias Waldekranz
But this new bridge port will not see any STP state > change notification and will remain FORWARDING, which is how the > standalone code leaves it in. > > Add a function to the bridge which retrieves the current STP state, such > that drivers can synchronize to it when they may have

Re: [RFC PATCH v2 net-next 05/16] net: dsa: sync up VLAN filtering state when joining the bridge

2021-03-22 Thread Tobias Waldekranz
emitted by the > bridge for this port. > > Signed-off-by: Vladimir Oltean > --- Reviewed-by: Tobias Waldekranz

Re: [RFC PATCH v2 net-next 06/16] net: dsa: sync multicast router state when joining the bridge

2021-03-22 Thread Tobias Waldekranz
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote: > From: Vladimir Oltean > > Make sure that the multicast router setting of the bridge is picked up > correctly by DSA when joining, regardless of whether there are > sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port > att

Re: [RFC PATCH v2 net-next 07/16] net: dsa: sync ageing time when joining the bridge

2021-03-22 Thread Tobias Waldekranz
creation time, so: > (a) drivers had to hardcode the initial value for the address ageing time, > because they didn't get any notification > (b) that hardcoded value can be out of sync, if the user changes the > ageing time before enslaving the port to the bridge > > Si

Re: [RFC PATCH v2 net-next 09/16] net: dsa: replay port and local fdb entries when joining the bridge

2021-03-22 Thread Tobias Waldekranz
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote: > From: Vladimir Oltean > > When a DSA port joins a LAG that already had an FDB entry pointing to it: > > ip link set bond0 master br0 > bridge fdb add dev bond0 00:01:02:03:04:05 master static > ip link set swp0 master bond0 > > the DSA port

Re: [RFC PATCH v2 net-next 15/16] net: dsa: return -EOPNOTSUPP when driver does not implement .port_lag_join

2021-03-22 Thread Tobias Waldekranz
7;ll think we're offloading the bridge master of the LAG, when in > fact we're not even offloading the LAG. In turn, this will make us set > skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't > like it. > > Signed-off-by: Vladimir Oltean > --- Reviewed-by: Tobias Waldekranz

Re: [RFC PATCH v2 net-next 16/16] net: bridge: switchdev: let drivers inform which bridge ports are offloaded

2021-03-22 Thread Tobias Waldekranz
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote: > From: Vladimir Oltean > > On reception of an skb, the bridge checks if it was marked as 'already > forwarded in hardware' (checks if skb->offload_fwd_mark == 1), and if it > is, it puts a mark of its own on that skb, with the switchdev mark

Re: [RFC PATCH v2 net-next 09/16] net: dsa: replay port and local fdb entries when joining the bridge

2021-03-22 Thread Tobias Waldekranz
On Mon, Mar 22, 2021 at 18:19, Vladimir Oltean wrote: > On Mon, Mar 22, 2021 at 04:44:41PM +0100, Tobias Waldekranz wrote: >> I do not know if it is a problem or not, more of an observation: This is >> not guaranteed to be an exact replay of the events that the bridge port &g

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-15 Thread Tobias Waldekranz
On Thu, Apr 15, 2021 at 02:39, Vladimir Oltean wrote: > On Wed, Apr 14, 2021 at 08:39:53PM +0200, Tobias Waldekranz wrote: >> In order to have two entries for the same destination, they must belong >> to different FIDs. But that FID is also used for automatic learning. So >

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote: > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >> On Sat, 10 Apr 2021 15:34:46 +0200 >> Ansuel Smith wrote: >> >> > Hi, >> > this is a respin of the Marek series in hope that this time we can >> > finally make some progress wi

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Mon, Apr 12, 2021 at 17:35, Vladimir Oltean wrote: > On Mon, Apr 12, 2021 at 02:46:11PM +0200, Tobias Waldekranz wrote: >> On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote: >> > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >> >> On S

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote: > On Mon, 12 Apr 2021 14:46:11 +0200 > Tobias Waldekranz wrote: > >> I agree. Unless you only have a few really wideband flows, a LAG will >> typically do a great job with balancing. This will happen without the >

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote: > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote: >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote: >> > On Mon, 12 Apr 2021 14:46:11 +0200 >> > Tobias Waldekranz wrote: >> > >&

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote: > On Mon, 12 Apr 2021 23:22:45 +0200 > Tobias Waldekranz wrote: > >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote: >> > On Mon, 12 Apr 2021 14:46:11 +0200 >> > Tobias Waldekranz wrote: >> > >&g

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote: > On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote: >> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote: >> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote: >> >> On Mon

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote: > On Tue, 13 Apr 2021 00:05:51 +0200 > Tobias Waldekranz wrote: > >> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote: >> > On Mon, 12 Apr 2021 23:22:45 +0200 >> > Tobias Waldekranz wrote: >> > >&g

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-12 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 01:09, Tobias Waldekranz wrote: > On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote: >> On Tue, 13 Apr 2021 00:05:51 +0200 >> Tobias Waldekranz wrote: >> >>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote: >>> > On Mo

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-13 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 01:54, Marek Behun wrote: > On Tue, 13 Apr 2021 01:13:53 +0200 > Tobias Waldekranz wrote: > >> > ...you could get the isolation in place. But you will still lookup the >> > DA in the ATU, and there you will find a destination of either cpu0 or &

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-13 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote: > On Tue, 13 Apr 2021 01:54:50 +0200 > Marek Behun wrote: > >> I will look into this, maybe ask some follow-up questions. > > Tobias, > > it seems that currently the LAGs in mv88e6xxx driver do not use the > HashTrunk feature (which can be enabled

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-13 Thread Tobias Waldekranz
On Tue, Apr 13, 2021 at 17:14, Marek Behun wrote: > On Tue, 13 Apr 2021 16:46:32 +0200 > Tobias Waldekranz wrote: > >> On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote: >> > On Tue, 13 Apr 2021 01:54:50 +0200 >> > Marek Behun wrote: >> > >> &g

Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support

2021-04-14 Thread Tobias Waldekranz
On Wed, Apr 14, 2021 at 17:14, Marek Behun wrote: > On Tue, 13 Apr 2021 20:16:24 +0200 > Tobias Waldekranz wrote: > >> You could imagine a different mode in which the DSA driver would receive >> the bucket allocation from the bond/team driver (which in turn could >

Re: [PATCH net 1/2] net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext

2021-01-16 Thread Tobias Waldekranz
aking VLAN filtering. > > When the VTU entry is initially created, those bits are all zero, and > we should make sure to keep them that way when the entry is updated. > > Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) > Signed-off-by: Rasmus Villemoes R

Re: [PATCH net-next 2/2] net: dsa: mv88e6xxx: use mv88e6185_g1_vtu_getnext() for the 6250

2021-01-16 Thread Tobias Waldekranz
n assembling the fid from VTU op [3:0] > and [11:8]. > > Signed-off-by: Rasmus Villemoes We might also want to give mv88e6250_g1_vtu_loadpurge the same treatment. Reviewed-by: Tobias Waldekranz Tested-by: Tobias Waldekranz

Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

2020-11-09 Thread Tobias Waldekranz
On Mon, Nov 09, 2020 at 02:30, Vladimir Oltean wrote: > On Mon, Nov 09, 2020 at 12:59:39AM +0100, Andrew Lunn wrote: >> We also need to make sure the static entries get removed correctly >> when a host moves. The mv88e6xxx will not replace a static entry with >> a dynamically learned one. It will

Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

2020-11-09 Thread Tobias Waldekranz
On Mon, Nov 09, 2020 at 12:03, Vladimir Oltean wrote: > On Mon, Nov 09, 2020 at 09:09:37AM +0100, Tobias Waldekranz wrote: >> one. But now you have also increased the background load of an already >> choked resource, the MDIO bus. > > In practice, DSA switches are already ve

Re: [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors

2020-11-09 Thread Tobias Waldekranz
On Mon Nov 9, 2020 at 3:38 PM CET, Vladimir Oltean wrote: > On Mon, Nov 09, 2020 at 02:31:11PM +0200, Vladimir Oltean wrote: > > I need to sit on this for a while. How many DSA drivers do we have that > > don't do SA learning in hardware for CPU-injected packets? ocelot/felix > > and mv88e6xxx? Who

[PATCH] scripts/gdb: relax requirement on symlink location

2016-10-14 Thread Tobias Waldekranz
The current construct for inserting the `scripts/gdb/` directory into the python path requires `vmlinux-gdb.py` to be symlinked in the root of the kernel build tree. By first resolving the symlink and inserting that path, the symlink can be placed in an arbitrary directory. Signed-off-by: Tobias