linux.git/drivers/net/dsa/b53/b53_priv.h, branch for-next

net: dsa: b53: Stop exporting b53_phylink_* routines

2024-04-25T18:46:37+00:00

They are not used outside of the b53_common.c file, no need to be
exported.

Signed-off-by: Florian Fainelli 
Reviewed-by: Russell King (Oracle) 
Link: https://lore.kernel.org/r/20240423183339.1368511-2-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski

net: dsa: b53: unexport and move b53_eee_enable_set()

2024-02-09T03:03:46+00:00

After commit f86ad77faf24 ("net: dsa: bcm_sf2: Utilize b53_{enable,
disable}_port"), bcm_sf2.c no longer calls b53_eee_enable_set(), and all
its callers are in b53_common.c.

We also need to move it, because it is called within b53_common.c before
its definition, and we want to avoid forward declarations.

Signed-off-by: Vladimir Oltean 
Reviewed-by: Simon Horman 
Acked-by: Florian Fainelli 
Link: https://lore.kernel.org/r/20240206112527.4132299-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski

ethtool: replace struct ethtool_eee with a new struct ethtool_keee on kernel side

2024-01-31T12:30:47+00:00

In order to pass EEE link modes beyond bit 32 to userspace we have to
complement the 32 bit bitmaps in struct ethtool_eee with linkmode
bitmaps. Therefore, similar to ethtool_link_settings and
ethtool_link_ksettings, add a struct ethtool_keee. In a first step
it's an identical copy of ethtool_eee. This patch simply does a
s/ethtool_eee/ethtool_keee/g for all users.
No functional change intended.

Suggested-by: Andrew Lunn 
Signed-off-by: Heiner Kallweit 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller

net: dsa: b53: mdio: add support for BCM53134

2023-03-27T07:29:54+00:00

Add support for the BCM53134 Ethernet switch in the existing b53 dsa driver.
BCM53134 is very similar to the BCM58XX series.

Signed-off-by: Paul Geurts 
Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller

net: dsa: b53: mmap: allow passing a chip ID

2023-03-23T04:38:04+00:00

BCM6318 and BCM63268 SoCs require a special handling for their RGMIIs, so we
should be able to identify them as a special BCM63xx switch.

Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Florian Fainelli 
Reviewed-by: Simon Horman 
Signed-off-by: Jakub Kicinski

net: dsa: b53: add support for BCM63xx RGMIIs

2023-03-21T12:25:27+00:00

BCM63xx RGMII ports require additional configuration in order to work.

Signed-off-by: Álvaro Fernández Rojas 
Reviewed-by: Andrew Lunn 
Link: https://lore.kernel.org/r/20230319220805.124024-1-noltari@gmail.com
Signed-off-by: Paolo Abeni

net: dsa: b53: convert to phylink_pcs

2022-05-01T16:51:06+00:00

Convert B53 to use phylink_pcs for the serdes rather than hooking it
into the MAC-layer callbacks.

Fixes: 81c1681cbb9f ("net: dsa: b53: mark as non-legacy")
Reviewed-by: Florian Fainelli 
Tested-by: Florian Fainelli 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: David S. Miller

net: dsa: pass extack to dsa_switch_ops :: port_mirror_add()

2022-03-18T00:42:47+00:00

Drivers might have error messages to propagate to user space, most
common being that they support a single mirror port.

Propagate the netlink extack so that they can inform user space in a
verbal way of their limitations.

Signed-off-by: Vladimir Oltean 
Signed-off-by: Jakub Kicinski

net: dsa: pass extack to .port_bridge_join driver methods

2022-02-27T11:06:14+00:00

As FDB isolation cannot be enforced between VLAN-aware bridges in lack
of hardware assistance like extra FID bits, it seems plausible that many
DSA switches cannot do it. Therefore, they need to reject configurations
with multiple VLAN-aware bridges from the two code paths that can
transition towards that state:

- joining a VLAN-aware bridge
- toggling VLAN awareness on an existing bridge

The .port_vlan_filtering method already propagates the netlink extack to
the driver, let's propagate it from .port_bridge_join too, to make sure
that the driver can use the same function for both.

Signed-off-by: Vladimir Oltean 
Signed-off-by: David S. Miller

net: dsa: request drivers to perform FDB isolation

2022-02-27T11:06:14+00:00

For DSA, to encourage drivers to perform FDB isolation simply means to
track which bridge does each FDB and MDB entry belong to. It then
becomes the driver responsibility to use something that makes the FDB
entry from one bridge not match the FDB lookup of ports from other
bridges.

The top-level functions where the bridge is determined are:
- dsa_port_fdb_{add,del}
- dsa_port_host_fdb_{add,del}
- dsa_port_mdb_{add,del}
- dsa_port_host_mdb_{add,del}

aka the pre-crosschip-notifier functions.

Changing the API to pass a reference to a bridge is not superfluous, and
looking at the passed bridge argument is not the same as having the
driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
method.

DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
and those do not have any dp->bridge information to retrieve, because
they are not in any bridge - they are merely the pipes that serve the
user ports that are in one or multiple bridges.

The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
in a larger "struct dsa_db" database. Although only databases associated
to bridges are notified for now, this API will be the starting point for
implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
entries on the CPU port which belong to the corresponding user port's
port database. These are supposed to match only when the port is
standalone.

It is better to introduce the API in its expected final form than to
introduce it for bridges first, then to have to change drivers which may
have made one or more assumptions.

Drivers can use the provided bridge.num, but they can also use a
different numbering scheme that is more convenient.

DSA must perform refcounting on the CPU and DSA ports by also taking
into account the bridge number. So if two bridges request the same local
address, DSA must notify the driver twice, once for each bridge.

In fact, if the driver supports FDB isolation, DSA must perform
refcounting per bridge, but if the driver doesn't, DSA must refcount
host addresses across all bridges, otherwise it would be telling the
driver to delete an FDB entry for a bridge and the driver would delete
it for all bridges. So introduce a bool fdb_isolation in drivers which
would make all bridge databases passed to the cross-chip notifier have
the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
say that all bridge databases are the same database - which is
essentially the legacy behavior.

Signed-off-by: Vladimir Oltean 
Signed-off-by: David S. Miller