lar DSA is implicit on all chips). As before, we use EDSA for all
chips that fully supports it.
In upcoming changes, we will use this information to support
dynamically changing the tag protocol.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
drive
The 'dsa-tag-protocol' is used to force a switch tree to use a
particular tag protocol, typically because the Ethernet controller
that it is connected to is not compatible with the default one.
Signed-off-by: Tobias Waldekranz
---
Documentation/devicetree/bindings/net/dsa/ds
.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 5 +++
net/dsa/dsa2.c| 103 ++
2 files changed, 91 insertions(+), 17 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 1259b0f40684..2b25fe1ad5b7 100644
--- a/include/net
, in those
cases, make sure to log the fact that an undocumented feature has been
enabled.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/mv88e6xxx/chip.c | 39
1 file changed, 39 insertions(+)
diff
Previously DSA ports were also included, on the assumption that the
protocol used by the CPU port had to the matched throughout the entire
tree.
As there is not yet any consumer in need of this, drop the call.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian
the tag
protocol is enforced. (Vladimir).
Tobias Waldekranz (5):
net: dsa: mv88e6xxx: Mark chips with undocumented EDSA tag support
net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol
net: dsa: Only notify CPU ports of changes to the tag protocol
net: dsa: Allow defaul
.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 5 +++
net/dsa/dsa2.c| 95 ++-
2 files changed, 83 insertions(+), 17 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 1259b0f40684..2b25fe1ad5b7 100644
--- a/include/net
, in those
cases, make sure to log the fact that an undocumented feature has been
enabled.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 39
1 file changed, 39 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa
The 'dsa,tag-protocol' is used to force a switch tree to use a
particular tag protocol, typically because the Ethernet controller
that it is connected to is not compatible with the default one.
Signed-off-by: Tobias Waldekranz
---
Documentation/devicetree/bindings/net/dsa/ds
Previously DSA ports were also included, on the assumption that the
protocol used by the CPU port had to the matched throughout the entire
tree.
As there is not yet any consumer in need of this, drop the call.
Signed-off-by: Tobias Waldekranz
---
net/dsa/switch.c | 25
r only listing the protocols that I have tested. As more people
test their drivers, they can add them. (Rob)
I did not change the property name, as I am not sure which vendor
prefix to use (if any). Since there is an existing "dsa,member"
property, "dsa" seemed reasonab
lar DSA is implicit on all chips). As before, we use EDSA for all
chips that fully supports it.
In upcoming changes, we will use this information to support
dynamically changing the tag protocol.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/c
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
>
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
>
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
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
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
&
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
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
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
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
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:
>> >
>&
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
>
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
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
On Sat, Mar 27, 2021 at 12:13, Rob Herring wrote:
> On Fri, Mar 26, 2021 at 11:56:48AM +0100, Tobias Waldekranz wrote:
>> The 'dsa,tag-protocol' is used to force a switch tree to use a
>> particular tag protocol, typically because the Ethernet controller
>>
On Sun, Mar 28, 2021 at 17:24, Andrew Lunn wrote:
> On Fri, Mar 26, 2021 at 11:56:46AM +0100, Tobias Waldekranz wrote:
>> All devices are capable of using regular DSA tags. Support for
>> Ethertyped DSA tags sort into three categories:
>>
>> 1. No support. Older ch
On Fri, Mar 26, 2021 at 14:57, Vladimir Oltean wrote:
> Hi Tobias,
>
> On Fri, Mar 26, 2021 at 11:56:47AM +0100, Tobias Waldekranz wrote:
>> } else {
>> -dst->tag_ops = dsa_tag_driver_get(tag_protocol);
>> -if (IS_ERR(dst->tag_o
The 'dsa,tag-protocol' is used to force a switch tree to use a
particular tag protocol, typically because the Ethernet controller
that it is connected to is not compatible with the default one.
Signed-off-by: Tobias Waldekranz
---
Documentation/devicetree/bindings/net/dsa/ds
d behavior, as the alternative is a very crippled
system. But, in those cases, make sure to log the fact that an
undocumented feature has been enabled.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 41 +---
drivers/net/dsa/mv88e6xxx/chip.h |
.
Signed-off-by: Tobias Waldekranz
---
This deviates from the advise given by Andrew in that we store the
switches' default protocol on the tree rather than the override
value. I chose this because you want to make sure that the tagger
(default or overwritten) is available at probe time, and since
ss or ignore the hardware
parser and thus robs working combinations of the ability to do RSS and
other nifty things. It was therefore decided to go with the option of
a DT override.
Tobias Waldekranz (3):
net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol
net: dsa: Allow defaul
On Thu, Mar 25, 2021 at 03:34, Vladimir Oltean wrote:
> On Wed, Mar 24, 2021 at 05:07:09PM +0100, Tobias Waldekranz wrote:
>> But even if the parser was enabled, it would never get anywhere since
>> the Ethertype would look like random garbage. Unless we have the soft
>> p
On Wed, Mar 24, 2021 at 17:08, Vladimir Oltean wrote:
> On Wed, Mar 24, 2021 at 04:02:52PM +0100, Tobias Waldekranz wrote:
>> On Wed, Mar 24, 2021 at 16:03, Vladimir Oltean wrote:
>> > On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
>> >> > I d
On Wed, Mar 24, 2021 at 16:03, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
>> > I don't see any place in the network stack that recalculates the FCS if
>> > NETIF_F_RXALL is set. Additionally, without NETIF_F_RXFCS, I don&
On Wed, Mar 24, 2021 at 13:34, Vladimir Oltean wrote:
> On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:
>> >> This is the tragedy: I know for a fact that a DSA soft parser exists,
>> >> but because of the aforementioned maze of NDAs and licen
On Wed, Mar 24, 2021 at 01:44, Andrew Lunn wrote:
>> This was my initial approach. It gets quite messy though. Since taggers
>> can be modules, there is no way of knowing if a supplied protocol name
>> is garbage ("asdf"), or just part of a module in an initrd that is not
>> loaded yet when you ar
On Wed, Mar 24, 2021 at 01:15, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 10:17:30PM +0100, Tobias Waldekranz wrote:
>> On Tue, Mar 23, 2021 at 21:03, Vladimir Oltean wrote:
>> > On Tue, Mar 23, 2021 at 03:48:51PM +0100, Tobias Waldekranz wrote:
>> >>
On Tue, Mar 23, 2021 at 21:03, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 03:48:51PM +0100, Tobias Waldekranz wrote:
>> On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
>> > The netdev_uses_dsa thing is a bit trashy, I think that a more polished
>> >
On Tue, Mar 23, 2021 at 09:53, Florian Fainelli wrote:
> On 3/23/2021 7:49 AM, Tobias Waldekranz wrote:
>> On Tue, Mar 23, 2021 at 13:41, Andrew Lunn wrote:
>>> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>>>> All devices are capable of using
On Tue, Mar 23, 2021 at 13:41, Andrew Lunn wrote:
> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>> All devices are capable of using regular DSA tags. Support for
>> Ethertyped DSA tags sort into three categories:
>>
>> 1. No support. Older ch
On Tue, Mar 23, 2021 at 13:35, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
>> All devices are capable of using regular DSA tags. Support for
>> Ethertyped DSA tags sort into three categories:
>>
>> 1. No support. Older ch
On Tue, Mar 23, 2021 at 12:52, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 11:45:03AM +0100, Tobias Waldekranz wrote:
>> On Thu, Mar 18, 2021 at 20:25, Tobias Waldekranz
>> wrote:
>> > Add support for offloading learning and broadcast flooding flags. With
>
On Thu, Mar 18, 2021 at 20:25, Tobias Waldekranz wrote:
> Add support for offloading learning and broadcast flooding flags. With
> this in place, mv88e6xx supports offloading of all bridge port flags
> that are currently supported by the bridge.
>
> Broadcast flooding is some
d behavior, as the alternative is a very crippled
system. But, in those cases, make sure to log the fact that an
undocumented feature has been enabled.
Signed-off-by: Tobias Waldekranz
---
In a system using an NXP T1023 SoC connected to a 6390X switch, we
noticed that TO_CPU frames where not reachi
On Sun, Mar 21, 2021 at 00:59, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> DSA is aware of switches with global VLAN filtering since the blamed
> commit, but it makes a bad decision when multiple bridges are spanning
> the same switch:
>
> ip link add br0 type bridge vlan_filtering 1
> ip
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
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
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
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
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
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
emitted by the
> bridge for this port.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: 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
t;
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
idge port is handled in the next
> patches.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
per-port broadcast flooding by (1) making sure to only set the subset
of ports that have it enabled whenever joining a new bridge or VLAN,
and (2) by updating all active databases whenever the setting is
changed on a port.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Florian Fainelli
---
drivers
Allow a user to control automatic learning per port.
Many chips have an explicit "LearningDisable"-bit that can be used for
this, but we opt for setting/clearing the PAV instead, as it works on
all devices at least as far back as 6083.
Signed-off-by: Tobias Waldekranz
Reviewed-by
The hardware has a somewhat quirky protocol for reading out the VTU
entry for a particular VID. But there is no reason why we cannot
create a better API for ourselves in the driver.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
drivers/net/dsa
bridge, it would.
This does not matter that much since we only ever send FROM_CPUs on
standalone ports, but it seems prudent to make sure that the initial
values match those that are applied after a bridging/unbridging cycle.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed
Use the conventional declaration style of a MAC address in the
kernel (u8 addr[ETH_ALEN]) for the broadcast address, then set it
using the existing helper.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/mv88e6xxx/chip.c | 4
Move the intricacies of correctly iterating over the VTU to a common
implementation.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Andrew Lunn
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/mv88e6xxx/chip.c | 100 ---
1 file changed
transform the request to target the
LAG instead.
Instead we document this known limitation and at least avoid wasting
any time on it.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
drivers/net/dsa/mv88e6xxx/chip.c | 7 +++
1 file changed, 7
the set of possible offloaded uppers.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
include/net/dsa.h | 14 ++
net/dsa/dsa_priv.h | 14 +-
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/include/net/dsa.h
xx_vtu_get handles VID 0 (Vladimir)
- Fixed off-by-one in mv88e6xxx_port_set_assoc_vector (Vladimir)
- Fast age all entries on port when disabling learning (Vladimir)
- Correctly detect bridge flags on LAG ports (Vladimir)
Tobias Waldekranz (8):
net: dsa: Add helper to resolve bridge port fro
per-port broadcast flooding by (1) making sure to only set the subset
of ports that have it enabled whenever joining a new bridge or VLAN,
and (2) by updating all active databases whenever the setting is
changed on a port.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 73
bridge, it would.
This does not matter that much since we only ever send FROM_CPUs on
standalone ports, but it seems prudent to make sure that the initial
values match those that are applied after a bridging/unbridging cycle.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed
Allow a user to control automatic learning per port.
Many chips have an explicit "LearningDisable"-bit that can be used for
this, but we opt for setting/clearing the PAV instead, as it works on
all devices at least as far back as 6083.
Signed-off-by: Tobias Waldekranz
---
drive
Use the conventional declaration style of a MAC address in the
kernel (u8 addr[ETH_ALEN]) for the broadcast address, then set it
using the existing helper.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The hardware has a somewhat quirky protocol for reading out the VTU
entry for a particular VID. But there is no reason why we cannot
create a better API for ourselves in the driver.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 45 ++--
1
Move the intricacies of correctly iterating over the VTU to a common
implementation.
Signed-off-by: Tobias Waldekranz
Reviewed-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx/chip.c | 100 ---
1 file changed, 64 insertions(+), 36 deletions(-)
diff --git a/drivers/net
hen disabling learning (Vladimir)
- Correctly detect bridge flags on LAG ports (Vladimir)
Tobias Waldekranz (8):
net: dsa: Add helper to resolve bridge port from DSA port
net: dsa: mv88e6xxx: Avoid useless attempts to fast-age LAGs
net: dsa: mv88e6xxx: Provide generic VTU iterator
net:
transform the request to target the
LAG instead.
Instead we document this known limitation and at least avoid wasting
any time on it.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b
the set of possible offloaded uppers.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 14 ++
net/dsa/dsa_priv.h | 14 +-
2 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index dac303edd33d..5c4340ecfeb2 100644
On Wed, Mar 17, 2021 at 21:29, Vladimir Oltean wrote:
> On Wed, Mar 17, 2021 at 07:45:46PM +0100, Tobias Waldekranz wrote:
>> On Wed, Mar 17, 2021 at 16:12, Vladimir Oltean wrote:
>> > On Mon, Mar 15, 2021 at 10:13:59PM +0100, Tobias Waldekranz wrote:
>> >>
On Wed, Mar 17, 2021 at 16:12, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 10:13:59PM +0100, Tobias Waldekranz wrote:
>> +if (flags.mask & BR_LEARNING) {
>> +u16 pav = (flags.val & BR_LEARNING) ? (1 << port) : 0;
>> +
>> +e
On Tue, Mar 16, 2021 at 11:39, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 10:14:00PM +0100, Tobias Waldekranz wrote:
>> These switches have two modes of classifying broadcast:
>>
>> 1. Broadcast is multicast.
>> 2. Broadcast is its own unique thing that is alwa
On Tue, Mar 16, 2021 at 11:27, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 10:13:59PM +0100, Tobias Waldekranz wrote:
>> Allow a user to control automatic learning per port.
>>
>> Many chips have an explicit "LearningDisable"-bit that can be used for
>>
On Tue, Mar 16, 2021 at 11:17, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 10:13:57PM +0100, Tobias Waldekranz wrote:
>> +static int mv88e6xxx_vtu_get(struct mv88e6xxx_chip *chip, u16 vid,
>> + struct mv88e6xxx_vtu_entry *entry)
>> {
>> +
On Tue, Mar 16, 2021 at 10:42, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 10:13:56PM +0100, Tobias Waldekranz wrote:
>> @@ -2184,25 +2230,7 @@ static int mv88e6xxx_port_db_dump(struct
>> mv88e6xxx_chip *chip, int port,
>> if (err)
>> return err;
On Tue, Mar 16, 2021 at 23:49, Vladimir Oltean wrote:
> On Tue, Mar 16, 2021 at 05:08:28PM +0100, Tobias Waldekranz wrote:
>> On Tue, Mar 16, 2021 at 01:49, Vladimir Oltean wrote:
>> > On Mon, Mar 15, 2021 at 08:54:13PM +0100, Tobias Waldekranz wrote:
>> >> There
given.
Reported-by: kernel test robot
Signed-off-by: Tobias Waldekranz
---
v2 primarily fixes an issue where VLAN uppers added on top of a bridge
would be interpreted by DSA as if it was added to a port. Make sure
that only VLAN uppers on ports we offload are considered.
There are a few open i
On Tue, Mar 16, 2021 at 13:24, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Add a short summary of the methods that a driver writer must implement
> for offloading a link aggregation group, and what is still missing.
>
> Cc: Tobias Waldekranz
> Signed-off-by: Vladim
On Tue, Mar 16, 2021 at 01:49, Vladimir Oltean wrote:
> On Mon, Mar 15, 2021 at 08:54:13PM +0100, Tobias Waldekranz wrote:
>> There are four kinds of events that have an inpact on VLAN
>
> impact
>
>> configuration of DSA ports:
>>
>> - Adding VLAN uppers
&g
The hardware has a somewhat quirky protocol for reading out the VTU
entry for a particular VID. But there is no reason why we cannot
create a better API for ourselves in the driver.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 45 ++--
1
per-port broadcast flooding by (1) making sure to only set the subset
of ports that have it enabled whenever joining a new bridge or VLAN,
and (2) by updating all active databases whenever the setting is
changed on a port.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 68
bridge, it would.
This does not matter that much since we only ever send FROM_CPUs on
standalone ports, but it seems prudent to make sure that the initial
values match those that are applied after a bridging/unbridging cycle.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c
Allow a user to control automatic learning per port.
Many chips have an explicit "LearningDisable"-bit that can be used for
this, but we opt for setting/clearing the PAV instead, as it works on
all devices at least as far back as 6083.
Signed-off-by: Tobias Waldekranz
---
drive
Move the intricacies of correctly iterating over the VTU to a common
implementation.
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 100 ---
1 file changed, 64 insertions(+), 36 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b
unicast and unknown
multicast. Instead we have to update the ATU entry for the broadcast
address for all currently used FIDs.
Tobias Waldekranz (5):
net: dsa: mv88e6xxx: Provide generic VTU iterator
net: dsa: mv88e6xxx: Remove some bureaucracy around querying the VTU
net: dsa: mv88e6xxx
given.
Signed-off-by: Tobias Waldekranz
---
I realize that this perhaps is a bit sprawling, but it is not obvious
to me how it could be split up. Happy to take suggestions.
I have tested this against Vladimir's comprehensive test suite posted
here:
https://lore.kernel.org/netdev/2021
On Wed, Mar 10, 2021 at 00:01, Vladimir Oltean wrote:
> On Tue, Mar 09, 2021 at 10:28:11PM +0100, Tobias Waldekranz wrote:
>> On Tue, Mar 09, 2021 at 12:40, Florian Fainelli wrote:
>> > On 3/9/21 10:42 AM, Tobias Waldekranz wrote:
>> >> There are three kinds of even
On Tue, Mar 09, 2021 at 12:40, Florian Fainelli wrote:
> On 3/9/21 10:42 AM, Tobias Waldekranz wrote:
>> There are three kinds of events that have an inpact on VLAN
>> configuration of DSA ports:
>>
>> - Adding of stacked VLANs
>> (ip link add de
are bridged, the expectation of the
> Linux network stack is that traffic received by other upper interfaces
> except the bridge is not captured by the bridge rx_handler, therefore
> not subject to forwarding. So the above setup should not do forwarding
> for VLAN ID 100, but it do
iding certain configs being
allowed or disallowed depending on the order in which commands are
given.
Signed-off-by: Tobias Waldekranz
---
There is still testing left to do on this, but I wanted to send early
in order show what I meant by "generic" VLAN validation in this
dis
On Mon, Mar 08, 2021 at 22:50, Vladimir Oltean wrote:
> On Mon, Mar 08, 2021 at 09:00:49PM +0100, Tobias Waldekranz wrote:
>> Alright, we do not want to lie to the stack, got it...
>
> [...]
>
>> ...hang on, are we OK with lying or not? Yes, I guess?
>
> I'm not
On Mon, Mar 08, 2021 at 19:00, Vladimir Oltean wrote:
> On Mon, Mar 08, 2021 at 05:44:46PM +0200, Vladimir Oltean wrote:
>> On Mon, Mar 08, 2021 at 04:04:04PM +0100, Tobias Waldekranz wrote:
>> > The dsa_slave_vlan_rx_{add,kill}_vid ndos are required for hardware
>> >
ation")
Signed-off-by: Tobias Waldekranz
---
drivers/net/dsa/mv88e6xxx/chip.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 903d619e08ed..0ba44bcac7da 100644
--- a/drive
assumption that if a driver supports VLAN offloading, it
will always use it, does not hold in certain edge cases.
Fixes: 9b236d2a69da ("net: dsa: Advertise the VLAN offload netdev ability only
if switch supports it")
Signed-off-by: Tobias Waldekranz
---
net/dsa/slave.c | 9
First, re-introduce the ability for drivers to signal that VLANs for
standalone ports are not offloaded.
Then, make sure that mv88e6xxx never offloads VLANs for standalone
ports.
Tobias Waldekranz (2):
net: dsa: Accept software VLANs for stacked interfaces
net: dsa: mv88e6xxx: Never apply
1 - 100 of 296 matches
Mail list logo
