.
- Support for both DSA and EDSA tagging.
Tobias Waldekranz (5):
net: bonding: Notify ports about their initial state
net: dsa: Don't offload port attributes on standalone ports
net: dsa: Link aggregation support
net: dsa: mv88e6xxx: Link aggregation support
net: dsa: tag_dsa: Sup
/ \
swp0 swp1
If vlan filtering was enabled on br0, swp0's and swp1's QMode was set
to "secure". This caused all untagged packets to be dropped, as their
default VID (0) was not loaded into the VTU.
Signed-off-by: Tobias Waldekranz
---
net/dsa/slave.c | 3 +++
1 file changed, 3
st), DSA will take a hands-off approach, allowing
the LAG to be formed as a pure software construct. This is reported
back through the extended ACK, but is otherwise transparent to the
user.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
---
I tr
can not associate with
any bond. Then the bond is joined. After that point no more
notifications are sent, so all ports remain disabled.
This change simply sends an extra notification once the port has been
linked to the upper to synchronize the initial state.
Signed-off-by: Tobias Waldekranz
not available in the tag,
frames are injected directly on the LAG interface and thus do never
pass through any DSA port interface on ingress.
Management frames (TO_CPU) are not affected and will pass through the
DSA port interface as usual.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Florian
Support offloading of LAGs to hardware. LAGs may be attached to a
bridge in which case VLANs, multicast groups, etc. are also offloaded
as usual.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c| 296 +++-
drivers/net/dsa/mv88e6xxx/global2.c
On Thu, Jan 14, 2021 at 02:50, Vladimir Oltean wrote:
> On Wed, Jan 13, 2021 at 09:42:54AM +0100, Tobias Waldekranz wrote:
>> Support offloading of LAGs to hardware. LAGs may be attached to a
>> bridge in which case VLANs, multicast groups, etc. are also offloaded
>> as usu
robot
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/global2.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/global2.h
b/drivers/net/dsa/mv88e6xxx/global2.h
index 60febaf4da76..253a79582a1d 100644
--- a/drivers/net/dsa/mv88e6xxx/global2.h
+
The kernel test robot kindly pointed out that Global 2 support in
mv88e6xxx is optional.
This also made me realize that we should verify that the driver and
hardware actually supports LAG offloading before trying to configure
it.
Tobias Waldekranz (2):
net: dsa: mv88e6xxx: Provide dummy
t;)
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 4
drivers/net/dsa/mv88e6xxx/chip.h | 9 +
2 files changed, 13 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index dcb1726b68cc..c48d166c2a70 100644
--- a/drive
mir).
- Simplify _has_lag predicate (Vladimir).
Tobias Waldekranz (2):
net: dsa: mv88e6xxx: Provide dummy implementations for trunk setters
net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware
drivers/net/dsa/mv88e6xxx/chip.c| 6 +-
drivers/net/dsa/mv88e6xxx/chip.h|
There are chips that do have Global 2 registers, and therefore trunk
mapping/mask tables are not available. Refuse the offload as early as
possible on those devices.
Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support")
Signed-off-by: Tobias Waldekranz
---
drive
t robot
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/global2.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/global2.h
b/drivers/net/dsa/mv88e6xxx/global2.h
index 60febaf4da76..253a7
On Fri, Jan 15, 2021 at 15:48, Andrew Lunn wrote:
> On Fri, Jan 15, 2021 at 04:36:49PM +0200, Vladimir Oltean wrote:
>> On Fri, Jan 15, 2021 at 03:30:30PM +0100, Andrew Lunn wrote:
>> > On Fri, Jan 15, 2021 at 11:58:33AM +0100, Tobias Waldekranz wrote:
>> > > Sup
On Fri, Jan 15, 2021 at 15:46, Jakub Kicinski wrote:
> On Sat, 16 Jan 2021 01:24:35 +0200 Vladimir Oltean wrote:
>> On Fri, Jan 15, 2021 at 03:02:46PM -0800, Jakub Kicinski wrote:
>> > On Fri, 15 Jan 2021 13:52:57 +0100 Tobias Waldekranz wrote:
>> > > The kernel
Treat addresses added to the bridge itself in the same way as regular
ports and send out a notification so that drivers may sync it down to
the hardware FDB.
Signed-off-by: Tobias Waldekranz
---
net/bridge/br_fdb.c | 4 ++--
net/bridge/br_private.h | 7 ---
net/bridge
extends the switchdev fdb notifications to include
the local flag, and to handle the case when an entry is added to the
bridge itself.
Patches 4 through 6 enables DSA to make use of those extensions.
Finally, enable assisted learning on the CPU port for mv88e6xxx.
Tobias Waldekranz (7):
net
Instead of having to add more and more arguments to
br_switchdev_fdb_call_notifiers, get rid of it and build the info
struct directly in br_switchdev_fdb_notify.
Signed-off-by: Tobias Waldekranz
---
net/bridge/br_switchdev.c | 41 +++
1 file changed, 11
classes can be discriminated.
This allows DSA-like devices to add local addresses to the hardware
FDB (with the CPU as the destination), thereby avoiding flows towards
the CPU being flooded by the switch as unknown unicast.
Signed-off-by: Tobias Waldekranz
---
include/net/switchdev.h | 1
but the following commit takes care of that case.
Signed-off-by: Tobias Waldekranz
---
net/dsa/slave.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index c5c81cba8259..dca393e45547 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/sla
n 1 master
Results in DSA adding an entry in the hardware FDB, pointing this
address towards the CPU port.
The same is true for entries added to the bridge itself, e.g:
$ bridge fdb add 02:00:de:ad:00:01 dev br0 vlan 1 self
Signed-off-by: Tobias Waldekranz
---
net/dsa/slave.c | 12 --
o the hardware FDB.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 91286d7b12c7..398f3cc8d2f3 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/driver
Now that notifications are sent out for addresses added to the bridge
itself, extend DSA to include those addresses in the hardware FDB when
assisted CPU port learning is enabled.
Signed-off-by: Tobias Waldekranz
---
net/dsa/slave.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion
On Thu, Jan 14, 2021 at 14:49, Rasmus Villemoes
wrote:
> Hi
>
> I've noticed something rather odd with my mv88e6250, which led me to the
> commit in the subject.
>
> First, the MAC address of the master device never seems to get learned
> (at least according to "mv88e6xxx_dump --atu"), so all pac
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
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
On Sun, Jul 19, 2020 at 14:43, Chris Healy wrote:
> On Sat, Jul 18, 2020 at 8:22 AM Marek Behun wrote:
>>
>> On Sat, 18 Jul 2020 17:05:14 +0200
>> Andrew Lunn wrote:
>>
>> > > If the traces were broken between the fiber module and the SERDES, I
>> > > should not see these counters incrementing.
On Mon, Jan 18, 2021 at 18:41, Andrew Lunn wrote:
> On Mon, Jan 18, 2021 at 06:31:19PM +0100, Tobias Waldekranz wrote:
>> On Sun, Jul 19, 2020 at 14:43, Chris Healy wrote:
>> > On Sat, Jul 18, 2020 at 8:22 AM Marek Behun wrote:
>> >>
>> >> On Sat, 18
On Mon, Jan 18, 2021 at 18:50, Andrew Lunn wrote:
>> I suppose the real solution is having userspace do some "bridge mdb add"
>> yoga, but since no code currently uses
>> MV88E6XXX_G1_ATU_DATA_STATE_MC_STATIC_DA_MGMT, I don't think there's any
>> way to actually achieve this. And I have no idea ho
On Sun, Jan 17, 2021 at 21:30, Vladimir Oltean wrote:
> Hi Tobias,
>
> On Sat, Jan 16, 2021 at 02:25:10AM +0100, Tobias Waldekranz wrote:
>> Some switchdev drivers, notably DSA, ignore all dynamically learned
>> address notifications (!added_by_user) as these are autonom
On Mon, Jan 18, 2021 at 20:01, Andrew Lunn wrote:
> On Mon, Jan 18, 2021 at 07:30:49PM +0100, Tobias Waldekranz wrote:
>> On Mon, Jan 18, 2021 at 18:50, Andrew Lunn wrote:
>> >> I suppose the real solution is having userspace do some "bridge mdb add"
>> >
On Mon, Jan 18, 2021 at 21:27, Vladimir Oltean wrote:
> On Mon, Jan 18, 2021 at 07:58:59PM +0100, Tobias Waldekranz wrote:
>> Ah I see, no I was not aware of that. I just saw that the entry towards
>> the CPU was added to the ATU, which it would in both cases. I.e. from
>>
On Mon, Jan 18, 2021 at 23:07, Rasmus Villemoes
wrote:
> On 18/01/2021 22.19, Vladimir Oltean wrote:
>> On Sat, Jan 16, 2021 at 02:42:12AM +0100, Tobias Waldekranz wrote:
>>>> What I'm _really_ trying to do is to get my mv88e6250 to participate in
>>>> an MR
On Sat, Jan 16, 2021 at 22:19, Pavel Šimerda wrote:
> Provide a debugging interface to read and write MDIO registers directly
> without the need for a device driver.
>
> This is extremely useful when debugging switch hardware and phy hardware
> issues. The interface provides proper locking for com
On Thu, Dec 10, 2020 at 00:21, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 11:01:25PM +0100, Tobias Waldekranz wrote:
>> It is not the Fibonacci sequence or anything, it is an integer in the
>> range 0..num_lags-1. I realize that some hardware probably allocate IDs
>>
On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
> Sorry it took so long. I wanted to understand:
> (a) where are the challenged for drivers to uniformly support software
> bridging when they already have code for bridge offloading. I found
> the following issues:
> - We have tagg
On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
> On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
>> 2. The issue Vladimir mentioned above. This is also a straight forward
>>fix, I have patch for tag_dsa, making sure that offload_fwd_mark is
>>
On Sun, Dec 13, 2020 at 22:18, Tobias Waldekranz wrote:
> On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
>> On Fri, Dec 11, 2020 at 09:50:24PM +0100, Tobias Waldekranz wrote:
>>> 2. The issue Vladimir mentioned above. This is also a straight forward
>>>fi
On Mon, Dec 14, 2020 at 13:42, Ido Schimmel wrote:
> On Mon, Dec 14, 2020 at 02:12:31AM +0200, Vladimir Oltean wrote:
>> On Sun, Dec 13, 2020 at 10:18:27PM +0100, Tobias Waldekranz wrote:
>> > On Sat, Dec 12, 2020 at 16:26, Vladimir Oltean wrote:
>> > > On Fri, De
can not associate with
any bond. Then the bond is joined. After that point no more
notifications are sent, so all ports remain disabled.
This change simply sends an extra notification once the port has been
linked to the upper to synchronize the initial state.
Signed-off-by: Tobias Waldekranz
st), DSA will take a hands-off approach, allowing
the LAG to be formed as a pure software construct. This is reported
back through the extended ACK, but is otherwise transparent to the
user.
Signed-off-by: Tobias Waldekranz
---
I tried in vain to win checkpatch's approval of the foreach mac
/ \
swp0 swp1
If vlan filtering was enabled on br0, swp0's and swp1's QMode was set
to "secure". This caused all untagged packets to be dropped, as their
default VID (0) was not loaded into the VTU.
Signed-off-by: Tobias Waldekranz
---
net/dsa/slave.c | 3 +++
1 file changed, 3
Support offloading of LAGs to hardware. LAGs may be attached to a
bridge in which case VLANs, multicast groups, etc. are also offloaded
as usual.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c| 298 +++-
drivers/net/dsa/mv88e6xxx/global2.c
not available in the tag,
frames are injected directly on the LAG interface and thus do never
pass through any DSA port interface on ingress.
Management frames (TO_CPU) are not affected and will pass through the
DSA port interface as usual.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Florian
t; v1:
- Properly propagate MDB operations.
- Support for bonding in addition to team.
- Fixed a locking bug in mv88e6xxx.
- Make sure ports are disabled-by-default in mv88e6xxx.
- Support for both DSA and EDSA tagging.
Tobias Waldekranz (5):
net: bonding: Notify ports about their initial state
On Wed, Dec 16, 2020 at 18:27, Vladimir Oltean wrote:
> On Wed, Dec 16, 2020 at 05:00:53PM +0100, Tobias Waldekranz wrote:
>> In a situation where a standalone port is indirectly attached to a
>> bridge (e.g. via a LAG) which is not offloaded, do not offload any
>> port a
On Wed, Dec 16, 2020 at 18:22, Vladimir Oltean wrote:
> On Wed, Dec 16, 2020 at 05:00:54PM +0100, Tobias Waldekranz wrote:
>> Monitor the following events and notify the driver when:
>>
>> - A DSA port joins/leaves a LAG.
>> - A LAG, made up of DSA ports, joins/leave
On Wed, Dec 16, 2020 at 20:02, Vladimir Oltean wrote:
> On Wed, Dec 16, 2020 at 05:00:54PM +0100, Tobias Waldekranz wrote:
>> +/* Drivers that benefit from having an ID associated with each
>> + * offloaded LAG should set this to the maximum number of
>> + * su
On Wed, Dec 16, 2020 at 20:44, Vladimir Oltean wrote:
> On Wed, Dec 16, 2020 at 05:00:54PM +0100, Tobias Waldekranz wrote:
>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>> index 183003e45762..deee4c0ecb31 100644
>> --- a/net/dsa/dsa2.c
>> +++ b/net/dsa/dsa2.c
>&
On Wed, Dec 16, 2020 at 21:04, Vladimir Oltean wrote:
> On Wed, Dec 16, 2020 at 05:00:55PM +0100, Tobias Waldekranz wrote:
>> Support offloading of LAGs to hardware. LAGs may be attached to a
>> bridge in which case VLANs, multicast groups, etc. are also offloaded
>> as usu
can not associate with
any bond. Then the bond is joined. After that point no more
notifications are sent, so all ports remain disabled.
This change simply sends an extra notification once the port has been
linked to the upper to synchronize the initial state.
Signed-off-by: Tobias Waldekranz
associated with any LAG, if that is
required. This is analogue to how switchdev events are replicated out
to all lower devices when reaching e.g. a LAG.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 97 +++
net/dsa/dsa2.c | 51
net
not available in the tag,
frames are injected directly on the LAG interface and thus do never
pass through any DSA port interface on ingress.
Management frames (TO_CPU) are not affected and will pass through the
DSA port interface as usual.
Signed-off-by: Tobias Waldekranz
---
net/dsa/dsa.c
Support offloading of LAGs to hardware. LAGs may be attached to a
bridge in which case VLANs, multicast groups, etc. are also offloaded
as usual.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c| 234 +++-
drivers/net/dsa/mv88e6xxx/chip.h
or both DSA and EDSA tagging.
Tobias Waldekranz (4):
net: bonding: Notify ports about their initial state
net: dsa: Link aggregation support
net: dsa: mv88e6xxx: Link aggregation support
net: dsa: tag_dsa: Support reception of packets from LAG devices
drivers/net/bonding/bond_main.
On Tue, Dec 01, 2020 at 03:37, Vladimir Oltean wrote:
> On Mon, Nov 30, 2020 at 03:06:08PM +0100, Tobias Waldekranz wrote:
>> +static void dsa_lag_release(struct kref *refcount)
>> +{
>> +struct dsa_lag *lag = container_of(refcount, struct dsa_lag, refcount);
>> +
On Tue, Dec 01, 2020 at 09:49, Peter Vollmer wrote:
> On Thu, Nov 26, 2020 at 10:41:44PM +0100, Tobias Waldekranz wrote:
>> On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
>> > - pinging from client0 (connected to lan0 ) to the bridge IP, the ping
>> > requests (
On Tue, Dec 01, 2020 at 15:29, Vladimir Oltean wrote:
> On Tue, Dec 01, 2020 at 09:13:57AM +0100, Tobias Waldekranz wrote:
>> I completely agree with your analysis. I will remove all the RCU
>> primitives in v3. Thank you.
>
> I expect that this also gives us a simple refc
On Tue, Dec 01, 2020 at 16:03, Vladimir Oltean wrote:
> On Mon, Nov 30, 2020 at 03:06:08PM +0100, Tobias Waldekranz wrote:
>> When a LAG joins a bridge, the DSA subsystem will treat that as each
>> individual port joining the bridge. The driver may look at the port's
>>
On Tue, Dec 01, 2020 at 22:04, Vladimir Oltean wrote:
> On Tue, Dec 01, 2020 at 03:29:53PM +0100, Tobias Waldekranz wrote:
>> On Tue, Dec 01, 2020 at 16:03, Vladimir Oltean wrote:
>> > On Mon, Nov 30, 2020 at 03:06:08PM +0100, Tobias Waldekranz wrote:
>> >> When
On Tue, Dec 01, 2020 at 23:24, Vladimir Oltean wrote:
> On Mon, Nov 30, 2020 at 03:06:10PM +0100, Tobias Waldekranz wrote:
>> Packets ingressing on a LAG that egress on the CPU port, which are not
>> classified as management, will have a FORWARD tag that does not
>> cont
can not associate with
any bond. Then the bond is joined. After that point no more
notifications are sent, so all ports remain disabled.
This change simply sends an extra notification once the port has been
linked to the upper to synchronize the initial state.
Signed-off-by: Tobias Waldekranz
RFC -> v1:
- Properly propagate MDB operations.
- Support for bonding in addition to team.
- Fixed a locking bug in mv88e6xxx.
- Make sure ports are disabled-by-default in mv88e6xxx.
- Support for both DSA and EDSA tagging.
Tobias Waldekranz (4):
net: bonding: Notify ports about their initial st
Support offloading of LAGs to hardware. LAGs may be attached to a
bridge in which case VLANs, multicast groups, etc. are also offloaded
as usual.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c| 234 +++-
drivers/net/dsa/mv88e6xxx/chip.h
associated with any LAG, if that is
required. This is analogue to how switchdev events are replicated out
to all lower devices when reaching e.g. a LAG.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 97 +
net/dsa/dsa2.c | 51 ++
net
not available in the tag,
frames are injected directly on the LAG interface and thus do never
pass through any DSA port interface on ingress.
Management frames (TO_CPU) are not affected and will pass through the
DSA port interface as usual.
Signed-off-by: Tobias Waldekranz
---
net/dsa/dsa.c
On Wed, Dec 02, 2020 at 12:07, Vladimir Oltean wrote:
> On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
>> +
>> +/* Link aggregates */
>> +struct {
>> +struct dsa_lag *pool;
>> +unsigned long *busy;
>> +
On Wed, Dec 02, 2020 at 10:58, Jakub Kicinski wrote:
> On Wed, 2 Dec 2020 10:13:54 +0100 Tobias Waldekranz wrote:
>> Monitor the following events and notify the driver when:
>>
>> - A DSA port joins/leaves a LAG.
>> - A LAG, made up of DSA ports, joins/leaves a bridg
On Wed, Dec 02, 2020 at 11:09, Jay Vosburgh wrote:
> Tobias Waldekranz wrote:
>
>>When creating a static bond (e.g. balance-xor), all ports will always
>>be enabled. This is set, and the corresponding notification is sent
>>out, before the port is linked to the bond uppe
On Wed, Dec 02, 2020 at 16:39, Jay Vosburgh wrote:
> Tobias Waldekranz wrote:
>>I could look at hoisting up the linking op before the first
>>notification. My main concern is that this is a new subsystem to me, so
>>I am not sure how to determine the adequate test coverag
On Thu, Dec 03, 2020 at 18:24, Vladimir Oltean wrote:
> On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
>> +static inline bool dsa_lag_offloading(struct dsa_switch_tree *dst)
>> +{
>> +return dst->lags.num > 0;
>> +}
>
> You assume
On Thu, Dec 03, 2020 at 22:09, Andrew Lunn wrote:
>> One could argue that if Linus had received an error instead, adapted his
>> teamd config and tried again, he would be a happier user and we might
>> not have to compete with his OS.
>>
>> I am not sure which way is the correct one, but I do not
On Thu, Dec 03, 2020 at 23:57, Vladimir Oltean wrote:
> On Thu, Dec 03, 2020 at 09:53:08PM +0100, Tobias Waldekranz wrote:
>> I am not sure which way is the correct one, but I do not think that it
>> necessarily _always_ correct to silently fallback to a non-offloaded
>>
On Fri, Dec 04, 2020 at 03:20, Andrew Lunn wrote:
>> +static int dsa_tree_setup_lags(struct dsa_switch_tree *dst)
>> +{
>> +struct dsa_port *dp;
>> +unsigned int num;
>> +
>> +list_for_each_entry(dp, &dst->ports, list)
>> +num = dp->ds->num_lags;
>> +
>> +list_for_each_
On Fri, Dec 04, 2020 at 02:56, Vladimir Oltean wrote:
> On Fri, Dec 04, 2020 at 12:12:32AM +0100, Tobias Waldekranz wrote:
>> You make a lot of good points. I think it might be better to force the
>> user to be explicit about their choice though. Imagine something like
>>
On Thu, Dec 03, 2020 at 20:18, Florian Fainelli wrote:
> On 12/3/2020 5:33 PM, Andrew Lunn wrote:
>>> Of course, neither is fully correct. There is always more to improve on
>>> the communication side of things.
>>
>> I wonder if switchdev needs to gain an enumeration API? A way to ask
>> the und
On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
> Hi Tobias,
>
> On Wed, Dec 02, 2020 at 10:13:54AM +0100, Tobias Waldekranz wrote:
>> Monitor the following events and notify the driver when:
>>
>> - A DSA port joins/leaves a LAG.
>> - A LAG, made up of
On Tue, Dec 08, 2020 at 18:37, Vladimir Oltean wrote:
> On Tue, Dec 08, 2020 at 04:33:19PM +0100, Tobias Waldekranz wrote:
>> On Tue, Dec 08, 2020 at 13:23, Vladimir Oltean wrote:
>> > Sorry it took so long. I wanted to understand:
>> > (a) where are the challeng
On Tue, Dec 08, 2020 at 00:26, Andrew Lunn wrote:
> On Mon, Dec 07, 2020 at 10:19:47PM +0100, Tobias Waldekranz wrote:
>> On Fri, Dec 04, 2020 at 03:20, Andrew Lunn wrote:
>> >> +static inline bool dsa_port_can_offload(struct dsa_port *dp,
>> >> +
On Wed, Dec 09, 2020 at 12:53, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 09:37:39AM +0100, Tobias Waldekranz wrote:
>> I will remove `struct dsa_lag` in v4.
>
> Ok, thanks.
> It would be nice if you could also make .port_lag_leave return an int code.
Sure.
On Wed, Dec 09, 2020 at 15:27, Andrew Lunn wrote:
>> I disagree. A LAG is one type of netdev that a DSA port can offload. The
>> other one is the DSA port's own netdev, i.e. what we have had since time
>> immemorial.
>>
>> dsa_port_offloads_netdev(dp, dev)?
>
> That is better.
...but there is an
On Wed, Dec 09, 2020 at 18:04, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 03:11:41PM +0100, Tobias Waldekranz wrote:
>> On Wed, Dec 09, 2020 at 12:53, Vladimir Oltean wrote:
>> > And I think that .port_lag_change passes more arguments than needed to
>> > the
On Thu Nov 19, 2020 at 1:51 PM CET, Vladimir Oltean wrote:
> I have tested these patches on ocelot/felix and all is OK there, I would
> appreciate if you could resend as non-RFC. In the case of my hardware,
For sure, I am working on it as we speak. I was mostly waiting for the
dsa-tag-unification
Properly propagate MDB operations.
- Support for bonding in addition to team.
- Fixed a locking bug in mv88e6xxx.
- Make sure ports are disabled-by-default in mv88e6xxx.
- Support for both DSA and EDSA tagging.
Tobias Waldekranz (4):
net: bonding: Notify ports about their initial state
net: d
can not associate with
any bond. Then the bond is joined. After that point no more
notifications are sent, so all ports remain disabled.
This change simply sends an extra notification once the port has been
linked to the upper to synchronize the initial state.
Signed-off-by: Tobias Waldekranz
Support offloading of LAGs to hardware. LAGs may be attached to a
bridge in which case VLANs, multicast groups, etc. are also offloaded
as usual.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c| 226 +++-
drivers/net/dsa/mv88e6xxx/chip.h
associated with any LAG, if that is
required. This is analogue to how switchdev events are replicated out
to all lower devices when reaching e.g. a LAG.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 66 +
net/dsa/dsa2.c | 3 +
net/dsa/dsa_priv.h | 31
not available in the tag,
frames are injected directly on the LAG interface and thus do never
pass through any DSA port interface on ingress.
Management frames (TO_CPU) are not affected and will pass through the
DSA port interface as usual.
Signed-off-by: Tobias Waldekranz
---
net/dsa/dsa.c
On Thu Nov 19, 2020 at 11:18 AM CET, Jay Vosburgh wrote:
> Tobias Waldekranz wrote:
>
> >When creating a static bond (e.g. balance-xor), all ports will always
> >be enabled. This is set, and the corresponding notification is sent
> >out, before the port is linked to the b
On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier
wrote:
> I don't think we have a way to distinguish from the DT if we are in
> SGMII-to-Fibre or in SGMII-to-{Copper + Fibre}, since the description is
> the same, we don't have any information in DT about wether or not the
> PHY is wired to a Copp
On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin
wrote:
> On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:
>> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier
>> wrote:
>> > I don't think we have a way to distinguish from the DT if
On Fri, Nov 20, 2020 at 01:00, Andrew Lunn wrote:
>> E.g. at Westermo we make switches with M12/M12X connectors [1] that
>> sometimes have a 1G PHY behind a 2-pair M12 connector (for complicated
>> legacy reasons). In such cases we have to remove 1000-HD/FD from the
>> advertised link modes. Being
On Fri, Nov 20, 2020 at 00:40, Russell King - ARM Linux admin
wrote:
> I think you're advocating calling the fiber interface "SGMII", which
> would be totally wrong.
>
> SGMII is a Cisco modification of 802.3 1000base-X to allow 10M and 100M
> speeds to be used over a single serdes lane in each d
On Fri, Nov 20, 2020 at 10:25, Russell King - ARM Linux admin
wrote:
> On Fri, Nov 20, 2020 at 10:36:01AM +0100, Maxime Chevallier wrote:
>> So maybe we could be a bit more generic, with something along these lines :
>>
>> ethernet-phy@0 {
>> ...
>>
>> mdi {
>> p
On Wed, Nov 25, 2020 at 15:09, Peter Vollmer wrote:
> Hi,
> I am still investigating the leaking packets problem we are having
> with a setup of an armada-3720 SOC and a 88E6341 switch ( connected
> via cpu port 5 , SGMII ,C_MODE=0xB, 2500 BASE-x). I now jumped to the
> net-next kernel (5.10.0-rc4
On Fri, Nov 20, 2020 at 14:30, Andrew Lunn wrote:
> On Thu, Nov 19, 2020 at 06:43:38PM -0800, Florian Fainelli wrote:
>> >
>> > Hi Tobias
>> >
>> > My comment last time was to statically allocated them at probe
>> > time. Worse case scenario is each port is alone in a LAG. Pointless,
>> > but so
On Thu, Nov 26, 2020 at 23:57, Andrew Lunn wrote:
>> If you go with the static array, you theoretically can not get the
>> equivalent of an ENOMEM. Practically though you have to iterate through
>> the array and look for a free entry, but you still have to put a return
>> statement at the bottom o
On Fri, Nov 27, 2020 at 17:28, Andrew Lunn wrote:
>> This is a digression, but I really do not get this shift from using
>> BUG()s to WARN()s in the kernel when you detect a violated invariant. It
>> smells of "On Error Resume Next" to me.
>
> A WARN() gives you a chance to actually use the machin
On Fri, Oct 16, 2020 at 00:27, Vladimir Oltean wrote:
> Currently any DSA switch that implements the multicast ops (properly,
> that is) gets these errors after just sitting for a while, with at least
> 2 ports bridged:
>
> [ 286.013814] mscc_felix :00:00.5 swp3: failed (err=-2) to del object
On Sat, Nov 28, 2020 at 00:27, Vladimir Oltean wrote:
> On Sat, Nov 28, 2020 at 12:58:10AM +0100, Tobias Waldekranz wrote:
>> That sounds like a good idea. We have run into another issue with the
>> MDB that maybe could be worked into this changeset. This is what we have
>>
1 - 100 of 296 matches
Mail list logo
