summaryrefslogtreecommitdiffstats
path: root/drivers/net/dsa/mv88e6xxx
Commit message (Collapse)AuthorAgeFilesLines
...
* | net: dsa: mv88e6xxx: fix mdio bus' phy_mask memberMarek Behún2023-03-211-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 2c7e46edbd03 ("net: dsa: mv88e6xxx: mask apparently non-existing phys during probing") added non-trivial bus->phy_mask in mv88e6xxx_mdio_register() in order to avoid excessive mdio bus transactions during probing. But the mask is incorrect for switches with non-zero phy_base_addr (such as 88E6341). Fix this. Fixes: 2c7e46edbd03 ("net: dsa: mv88e6xxx: mask apparently non-existing phys during probing") Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20230319140238.9470-1-kabel@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: dsa: mv88e6xxx: mask apparently non-existing phys during probingKlaus Kudielka2023-03-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | To avoid excessive mdio bus transactions during probing, mask all phy addresses that do not exist (there is a 1:1 mapping between switch port number and phy address). Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: move call to mv88e6xxx_mdios_register()Klaus Kudielka2023-03-171-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Call the rather expensive mv88e6xxx_mdios_register() at the beginning of mv88e6xxx_setup(). This avoids the double call via mv88e6xxx_probe() during boot. For symmetry, call mv88e6xxx_mdios_unregister() at the end of mv88e6xxx_teardown(). Link: https://lore.kernel.org/lkml/449bde236c08d5ab5e54abd73b645d8b29955894.camel@gmail.com/ Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: re-order functionsKlaus Kudielka2023-03-171-179/+179
| | | | | | | | | | | | | | | | | | | | | | | | Move mv88e6xxx_setup() below mv88e6xxx_mdios_register(), so that we are able to call the latter one from here. Do the same thing for the inverse functions. Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: don't dispose of Global2 IRQ mappings from mdiobus codeVladimir Oltean2023-03-171-16/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | irq_find_mapping() does not need irq_dispose_mapping(), only irq_create_mapping() does. Calling irq_dispose_mapping() from mv88e6xxx_g2_irq_mdio_free() and from the error path of mv88e6xxx_g2_irq_mdio_setup() effectively means that the mdiobus logic (for internal PHY interrupts) is disposing of a hwirq->virq mapping which it is not responsible of (but instead, the function pair mv88e6xxx_g2_irq_setup() + mv88e6xxx_g2_irq_free() is). With the current code structure, this isn't such a huge problem, because mv88e6xxx_g2_irq_mdio_free() is called relatively close to the real owner of the IRQ mappings: mv88e6xxx_remove() -> mv88e6xxx_unregister_switch() -> mv88e6xxx_mdios_unregister() -> mv88e6xxx_g2_irq_mdio_free() -> mv88e6xxx_g2_irq_free() and the switch isn't 'live' in any way such that it would be able of generating interrupts at this point (mv88e6xxx_unregister_switch() has been called). However, there is a desire to split mv88e6xxx_mdios_unregister() and mv88e6xxx_g2_irq_free() such that mv88e6xxx_mdios_unregister() only gets called from mv88e6xxx_teardown(). This is much more problematic, as can be seen below. In a cross-chip scenario (say 3 switches d0032004.mdio-mii:10, d0032004.mdio-mii:11 and d0032004.mdio-mii:12 which form a single DSA tree), it is possible to unbind the device driver from a single switch (say d0032004.mdio-mii:10). When that happens, mv88e6xxx_remove() will be called for just that one switch, and this will call mv88e6xxx_unregister_switch() which will tear down the entire tree (calling mv88e6xxx_teardown() for all 3 switches). Assuming mv88e6xxx_mdios_unregister() was moved to mv88e6xxx_teardown(), at this stage, all 3 switches will have called irq_dispose_mapping() on their mdiobus virqs. When we bind again the device driver to d0032004.mdio-mii:10, mv88e6xxx_probe() is called for it, which calls dsa_register_switch(). The DSA tree is now complete again, and mv88e6xxx_setup() is called for all 3 switches. Also assuming that mv88e6xxx_mdios_register() is moved to mv88e6xxx_setup() (the 2 assumptions go together), at this point, d0032004.mdio-mii:11 and d0032004.mdio-mii:12 don't have an IRQ mapping for the internal PHYs anymore, as they've disposed of it in mv88e6xxx_teardown(). Whereas switch d0032004.mdio-mii:10 has re-created it, because its code path comes from mv88e6xxx_probe(). Simply put, this change prepares the driver to handle the movement of mv88e6xxx_mdios_register() to mv88e6xxx_setup() for cross-chip DSA trees. Also, the code being deleted was partially wrong anyway (in a way which may have hidden this other issue). mv88e6xxx_g2_irq_mdio_setup() populates bus->irq[] starting with offset chip->info->phy_base_addr, but the teardown path doesn't apply that offset too. So it disposes of virq 0 for phy = [ 0, phy_base_addr ). All switch families have phy_base_addr = 0, except for MV88E6141 and MV88E6341 which have it as 0x10. I guess those families would have happened to work by mistake in cross-chip scenarios too. I'm deleting the body of mv88e6xxx_g2_irq_mdio_free() but leaving its call sites and prototype in place. This is because, if we ever need to add back some teardown procedure in the future, it will be perhaps error-prone to deduce the proper call sites again. Whereas like this, no extra code should get generated, it shouldn't bother anybody. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250, 6290Vladimir Oltean2023-03-161-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 3 classes of switch families that the driver is aware of, as far as mv88e6xxx_change_mtu() is concerned: - MTU configuration is available per port. Here, the chip->info->ops->port_set_jumbo_size() method will be present. - MTU configuration is global to the switch. Here, the chip->info->ops->set_max_frame_size() method will be present. - We don't know how to change the MTU. Here, none of the above methods will be present. Switch families MV88E6165, MV88E6191, MV88E6220, MV88E6250 and MV88E6290 fall in category 3. The blamed commit has adjusted the MTU for all 3 categories by EDSA_HLEN (8 bytes), resulting in a new maximum MTU of 1492 being reported by the driver for these switches. I don't have the hardware to test, but I do have a MV88E6390 switch on which I can simulate this by commenting out its .port_set_jumbo_size definition from mv88e6390_ops. The result is this set of messages at probe time: mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 1 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 2 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 3 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 4 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 5 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 6 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 7 mv88e6085 d0032004.mdio-mii:10: nonfatal error -34 setting MTU to 1500 on port 8 It is highly implausible that there exist Ethernet switches which don't support the standard MTU of 1500 octets, and this is what the DSA framework says as well - the error comes from dsa_slave_create() -> dsa_slave_change_mtu(slave_dev, ETH_DATA_LEN). But the error messages are alarming, and it would be good to suppress them. As a consequence of this unlikeliness, we reimplement mv88e6xxx_get_max_mtu() and mv88e6xxx_change_mtu() on switches from the 3rd category as follows: the maximum supported MTU is 1500, and any request to set the MTU to a value larger than that fails in dev_validate_mtu(). Fixes: b9c587fed61c ("dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: Enable PTP receive for mv88e6390Kurt Kanzenbach2023-01-166-3/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The switch receives management traffic such as STP and LLDP. However, PTP messages are not received, only transmitted. Ideally, the switch would trap all PTP messages to the management CPU. This particular switch has a PTP block which identifies PTP messages and traps them to a dedicated port. There is a register to program this destination. This is not used at the moment. Therefore, program it to the same port as the MGMT traffic is trapped to. This allows to receive PTP messages as soon as timestamping is enabled. In addition, the datasheet mentions that this register is not valid e.g., for 6190 variants. So, add a new PTP operation which is added for the 6390 and 6290 devices. Tested simply like this on Marvell 88E6390, revision 1: |/ # ptp4l -2 -i lan4 --tx_timestamp_timeout=40 -m |[...] |ptp4l[147.450]: master offset 56 s2 freq +1262 path delay 413 |ptp4l[148.450]: master offset 22 s2 freq +1244 path delay 434 |ptp4l[149.450]: master offset 5 s2 freq +1234 path delay 446 |ptp4l[150.451]: master offset 3 s2 freq +1233 path delay 451 |ptp4l[151.451]: master offset 1 s2 freq +1232 path delay 451 |ptp4l[152.451]: master offset -3 s2 freq +1229 path delay 451 |ptp4l[153.451]: master offset 9 s2 freq +1240 path delay 451 Link: https://lore.kernel.org/r/CAFSKS=PJBpvtRJxrR4sG1hyxpnUnQpiHg4SrUNzAhkWnyt9ivg@mail.gmail.com Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: Separate C22 and C45 transactionsAndrew Lunn2023-01-107-85/+225
| | | | | | | | | | | | The global2 SMI MDIO bus driver can perform both C22 and C45 transfers. Create separate functions for each and register the C45 versions using the new API calls where appropriate. Update the SERDES code to make use of these new accessors. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: mac-auth/MAB implementationHans J. Schultz2023-01-106-6/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implementation for the Marvell mv88e6xxx chip series is based on handling ATU miss violations occurring when packets ingress on a port that is locked with learning on. This will trigger a SWITCHDEV_FDB_ADD_TO_BRIDGE event, which will result in the bridge module adding a locked FDB entry. This bridge FDB entry will not age out as it has the extern_learn flag set. Userspace daemons can listen to these events and either accept or deny access for the host, by either replacing the locked FDB entry with a simple entry or leave the locked entry. If the host MAC address is already present on another port, a ATU member violation will occur, but to no real effect, and the packet will be dropped in hardware. Statistics on these violations can be shown with the command and example output of interest: ethtool -S ethX NIC statistics: ... atu_member_violation: 5 atu_miss_violation: 23 ... Where ethX is the interface of the MAB enabled port. Furthermore, as added vlan interfaces where the vid is not added to the VTU will cause ATU miss violations reporting the FID as MV88E6XXX_FID_STANDALONE, we need to check and skip the miss violations handling in this case. Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: mv88e6xxx: shorten the locked section in ↵Hans J. Schultz2023-01-101-8/+8
| | | | | | | | | | | | | | | | | mv88e6xxx_g1_atu_prob_irq_thread_fn() As only the hardware access functions up til and including mv88e6xxx_g1_atu_mac_read() called under the interrupt handler need to take the chip lock, we release the chip lock after this call. The follow up code that handles the violations can run without the chip lock held. In further patches, the violation handler function will even be incompatible with having the chip lock held. This due to an AB/BA ordering inversion with rtnl_lock(). Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: mv88e6xxx: change default return of mv88e6xxx_port_bridge_flagsHans J. Schultz2023-01-101-1/+1
| | | | | | | | | | | | | | | The default return value -EOPNOTSUPP of mv88e6xxx_port_bridge_flags() came from the return value of the DSA method port_egress_floods() in commit 4f85901f0063 ("net: dsa: mv88e6xxx: add support for bridge flags"), but the DSA API was changed in commit a8b659e7ff75 ("net: dsa: act as passthrough for bridge port flags"), resulting in the return value -EOPNOTSUPP not being valid anymore, and sections for new flags will not need to set the return value to zero on success, as with the new mab flag added in a following patch. Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: mv88e6xxx: depend on PTP conditionallyJohnny S. Lee2022-12-261-2/+2
| | | | | | | | | | | | | | | | | | | PTP hardware timestamping related objects are not linked when PTP support for MV88E6xxx (NET_DSA_MV88E6XXX_PTP) is disabled, therefore NET_DSA_MV88E6XXX should not depend on PTP_1588_CLOCK_OPTIONAL regardless of NET_DSA_MV88E6XXX_PTP. Instead, condition more strictly on how NET_DSA_MV88E6XXX_PTP's dependencies are met, making sure that it cannot be enabled when NET_DSA_MV88E6XXX=y and PTP_1588_CLOCK=m. In other words, this commit allows NET_DSA_MV88E6XXX to be built-in while PTP_1588_CLOCK is a module, as long as NET_DSA_MV88E6XXX_PTP is prevented from being enabled. Fixes: e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies") Signed-off-by: Johnny S. Lee <foss@jsl.io> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: avoid reg_lock deadlock in mv88e6xxx_setup_port()Vladimir Oltean2022-12-151-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the blamed commit, it was not noticed that one implementation of chip->info->ops->phylink_get_caps(), called by mv88e6xxx_get_caps(), may access hardware registers, and in doing so, it takes the mv88e6xxx_reg_lock(). Namely, this is mv88e6352_phylink_get_caps(). This is a problem because mv88e6xxx_get_caps(), apart from being a top-level function (method invoked by dsa_switch_ops), is now also directly called from mv88e6xxx_setup_port(), which runs under the mv88e6xxx_reg_lock() taken by mv88e6xxx_setup(). Therefore, when running on mv88e6352, the reg_lock would be acquired a second time and the system would deadlock on driver probe. The things that mv88e6xxx_setup() can compete with in terms of register access with are the IRQ handlers and MDIO bus operations registered by mv88e6xxx_probe(). So there is a real need to acquire the register lock. The register lock can, in principle, be dropped and re-acquired pretty much at will within the driver, as long as no operations that involve waiting for indirect access to complete (essentially, callers of mv88e6xxx_smi_direct_wait() and mv88e6xxx_wait_mask()) are interrupted with the lock released. However, I would guess that in mv88e6xxx_setup(), the critical section is kept open for such a long time just in order to optimize away multiple lock/unlock operations on the registers. We could, in principle, drop the reg_lock right before the mv88e6xxx_setup_port() -> mv88e6xxx_get_caps() call, and re-acquire it immediately afterwards. But this would look ugly, because mv88e6xxx_setup_port() would release a lock which it didn't acquire, but the caller did. A cleaner solution to this issue comes from the observation that struct mv88e6xxxx_ops methods generally assume they are called with the reg_lock already acquired. Whereas mv88e6352_phylink_get_caps() is more the exception rather than the norm, in that it acquires the lock itself. Let's enforce the same locking pattern/convention for chip->info->ops->phylink_get_caps() as well, and make mv88e6xxx_get_caps(), the top-level function, acquire the register lock explicitly, for this one implementation that will access registers for port 4 to work properly. This means that mv88e6xxx_setup_port() will no longer call the top-level function, but the low-level mv88e6xxx_ops method which expects the correct calling context (register lock held). Compared to chip->info->ops->phylink_get_caps(), mv88e6xxx_get_caps() also fixes up the supported_interfaces bitmap for internal ports, since that can be done generically and does not require per-switch knowledge. That's code which will no longer execute, however mv88e6xxx_setup_port() doesn't need that. It just needs to look at the mac_capabilities bitmap. Fixes: cc1049ccee20 ("net: dsa: mv88e6xxx: fix speed setting for CPU/DSA ports") Reported-by: Maksim Kiselev <bigunclemax@gmail.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Maksim Kiselev <bigunclemax@gmail.com> Link: https://lore.kernel.org/r/20221214110120.3368472-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: mv88e6xxx: replace VTU violation prints with trace pointsVladimir Oltean2022-12-122-4/+33
| | | | | | | | | | | | | | | | | | | | | | It is possible to trigger these VTU violation messages very easily, it's only necessary to send packets with an unknown VLAN ID to a port that belongs to a VLAN-aware bridge. Do a similar thing as for ATU violation messages, and hide them in the kernel's trace buffer. New usage model: $ trace-cmd list | grep mv88e6xxx mv88e6xxx mv88e6xxx:mv88e6xxx_vtu_miss_violation mv88e6xxx:mv88e6xxx_vtu_member_violation $ trace-cmd report Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Saeed Mahameed <saeed@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: replace ATU violation prints with trace pointsVladimir Oltean2022-12-124-9/+86
| | | | | | | | | | | | | | | | | | | | | | | | | In applications where the switch ports must perform 802.1X based authentication and are therefore locked, ATU violation interrupts are quite to be expected as part of normal operation. The problem is that they currently spam the kernel log, even if rate limited. Create a series of trace points, all derived from the same event class, which log these violations to the kernel's trace buffer, which is both much faster and much easier to ignore than printing to a serial console. New usage model: $ trace-cmd list | grep mv88e6xxx mv88e6xxx mv88e6xxx:mv88e6xxx_atu_full_violation mv88e6xxx:mv88e6xxx_atu_miss_violation mv88e6xxx:mv88e6xxx_atu_member_violation $ trace-cmd record -e mv88e6xxx sleep 10 Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Saeed Mahameed <saeed@kernel.org> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: read FID when handling ATU violationsHans J. Schultz2022-12-121-11/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an ATU violation occurs, the switch uses the ATU FID register to report the FID of the MAC address that incurred the violation. It would be good for the driver to know the FID value for purposes such as logging and CPU-based authentication. Up until now, the driver has been calling the mv88e6xxx_g1_atu_op() function to read ATU violations, but that doesn't do exactly what we want, namely it calls mv88e6xxx_g1_atu_fid_write() with FID 0. (side note, the documentation for the ATU Get/Clear Violation command says that writes to the ATU FID register have no effect before the operation starts, it's only that we disregard the value that this register provides once the operation completes) So mv88e6xxx_g1_atu_fid_write() is not what we want, but rather mv88e6xxx_g1_atu_fid_read(). However, the latter doesn't exist, we need to write it. The remainder of mv88e6xxx_g1_atu_op() except for mv88e6xxx_g1_atu_fid_write() is still needed, namely to send a GET_CLR_VIOLATION command to the ATU. In principle we could have still kept calling mv88e6xxx_g1_atu_op(), but the MDIO writes to the ATU FID register are pointless, but in the interest of doing less CPU work per interrupt, write a new function called mv88e6xxx_g1_read_atu_violation() and call it. The FID will be the port default FID as set by mv88e6xxx_port_set_fid() if the VID from the packet cannot be found in the VTU. Otherwise it is the FID derived from the VTU entry associated with that VID. Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: remove ATU age out violation printVladimir Oltean2022-12-121-6/+0
| | | | | | | | | | | | Currently, the MV88E6XXX_PORT_ASSOC_VECTOR_INT_AGE_OUT bit (interrupt on age out) is not enabled by the driver, and as a result, the print for age out violations is dead code. Remove it until there is some way for this to be triggered. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2022-12-081-2/+5
|\ | | | | | | | | | | No conflicts. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net: dsa: mv88e6xxx: accept phy-mode = "internal" for internal PHY portsVladimir Oltean2022-12-071-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ethernet-controller dt-schema, mostly pushed forward by Linux, has the "internal" PHY mode for denoting MAC connections to an internal PHY. U-Boot may provide device tree blobs where this phy-mode is specified, so make the Linux driver accept them. It appears that the current behavior with phy-mode = "internal" was introduced when mv88e6xxx started reporting supported_interfaces to phylink. Prior to that, I don't think it would have any issues accepting this phy-mode. Fixes: d4ebf12bcec4 ("net: dsa: mv88e6xxx: populate supported_interfaces and mac_capabilities") Link: https://lore.kernel.org/linux-arm-kernel/20221205172709.kglithpbhdbsakvd@skbuf/T/ Reported-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Tim Harvey <tharvey@gateworks.com> # imx6q-gw904.dts Link: https://lore.kernel.org/r/20221205194845.2131161-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: devlink: let the core report the driver name instead of the driversVincent Mailhol2022-11-301-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver name is available in device_driver::name. Right now, drivers still have to report this piece of information themselves in their devlink_ops::info_get callback function. In order to factorize code, make devlink_nl_info_fill() add the driver name attribute. Now that the core sets the driver name attribute, drivers are not supposed to call devlink_info_driver_name_put() anymore. Remove devlink_info_driver_name_put() and clean-up all the drivers using this function in their callback. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Tested-by: Ido Schimmel <idosch@nvidia.com> # mlxsw Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: enable set_policyAngelo Dureghello2022-11-111-0/+2
| | | | | | | | | | | | | | | | | | Enabling set_policy capability for mv88e6321. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221110091027.998073-1-angelo.dureghello@timesys.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: mv88e6xxx: Add RGMII delay to 88E6320Steffen Bätz2022-10-313-0/+13
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the .port_set_rgmii_delay hook is missing for the 88E6320 family, which causes failure to retrieve an IP address via DHCP. Add mv88e6320_port_set_rgmii_delay() that allows applying the RGMII delay for ports 2, 5, and 6, which are the only ports that can be used in RGMII mode. Tested on a custom i.MX8MN board connected to an 88E6320 switch. This change also applies safely to the 88E6321 variant. The only difference between 88E6320 versus 88E6321 is the temperature grade and pinout. They share exactly the same MDIO register map for ports 2, 5, and 6, which are the only ports that can be used in RGMII mode. Signed-off-by: Steffen Bätz <steffen@innosonix.de> [fabio: Improved commit log and extended it to mv88e6321_ops] Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20221028163158.198108-1-festevam@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: remove unnecessary dev_set_drvdata()Yang Yingliang2022-09-221-2/+0
| | | | | | | | Remove unnecessary dev_set_drvdata() in ->remove(), the driver_data will be set to NULL in device_unbind_cleanup() after calling ->remove(). Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: propagate extack to port_lag_joinVladimir Oltean2022-09-201-8/+19
| | | | | | | | | | | | Drivers could refuse to offload a LAG configuration for a variety of reasons, mainly having to do with its TX type. Additionally, since DSA masters may now also be LAG interfaces, and this will translate into a call to port_lag_join on the CPU ports, there may be extra restrictions there. Propagate the netlink extack to this DSA method in order for drivers to give a meaningful error message back to the user. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: move from strlcpy with unused retval to strscpyWolfram Sang2022-08-311-1/+1
| | | | | | | | | | | | Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for CAN Link: https://lore.kernel.org/r/20220830201457.7984-1-wsa+renesas@sang-engineering.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Allow external SMI if serialMarcus Carlberg2022-08-261-1/+1
| | | | | | | | | | | | | | | | p0_mode set to one of the supported serial mode should not prevent configuring the external SMI interface in mv88e6xxx_g2_scratch_gpio_set_smi. The current masking of the p0_mode only checks the first 2 bits. This results in switches supporting serial mode cannot setup external SMI on certain serial modes (Ex: 1000BASE-X and SGMII). Extend the mask of the p0_mode to include the reduced modes and serial modes as allowed modes for the external SMI interface. Signed-off-by: Marcus Carlberg <marcus.carlberg@axis.com> Link: https://lore.kernel.org/r/20220824093706.19049-1-marcus.carlberg@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: support RGMII cmodeMarcus Carlberg2022-08-262-0/+27
| | | | | | | | | | | | | | | Since the probe defaults all interfaces to the highest speed possible (10GBASE-X in mv88e6393x) before the phy mode configuration from the devicetree is considered it is currently impossible to use port 0 in RGMII mode. This change will allow RGMII modes to be configurable for port 0 enabling port 0 to be configured as RGMII as well as serial depending on configuration. Signed-off-by: Marcus Carlberg <marcus.carlberg@axis.com> Link: https://lore.kernel.org/r/20220822144136.16627-1-marcus.carlberg@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: fix speed setting for CPU/DSA portsMarcin Wojtas2022-07-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | Commit 3c783b83bd0f ("net: dsa: mv88e6xxx: get rid of SPEED_MAX setting") stopped relying on SPEED_MAX constant and hardcoded speed settings for the switch ports and rely on phylink configuration. It turned out, however, that when the relevant code is called, the mac_capabilites of CPU/DSA port remain unset. mv88e6xxx_setup_port() is called via mv88e6xxx_setup() in dsa_tree_setup_switches(), which precedes setting the caps in phylink_get_caps down in the chain of dsa_tree_setup_ports(). As a result the mac_capabilites are 0 and the default speed for CPU/DSA port is 10M at the start. To fix that, execute mv88e6xxx_get_caps() and obtain the capabilities driectly. Fixes: 3c783b83bd0f ("net: dsa: mv88e6xxx: get rid of SPEED_MAX setting") Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220726230918.2772378-1-mw@semihalf.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: get rid of SPEED_MAX settingRussell King2022-06-233-33/+30
| | | | | | | | | | | | | | Currently, all the device specific speed setting functions convert SPEED_MAX to the actual speed of the port. Rather than having each of the mv88e6xxx chip specifics handling SPEED_MAX, derive it from the mac_capabilities instead. This is only needed for CPU and DSA ports, so move the logic up into mv88e6xxx_setup_port() - which allows us to kill off all users of SPEED_MAX throughout the driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: remove mv88e6065 dead codeRussell King (Oracle)2022-06-232-17/+0
| | | | | | | | Remove mv88e6065_port_set_speed_duplex() - this is never called, and thus is completely redundant. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: correctly report serdes link failureRussell King (Oracle)2022-06-081-0/+8
| | | | | | | | | | Phylink wants to know if the link has dropped since the last time state was retrieved, and the BMSR gives us that. Read the BMSR and use it when deciding the link state. Fill in the an_complete member as well for the emulated PHY state. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: fix BMSR error to be consistent with othersRussell King (Oracle)2022-06-081-1/+1
| | | | | | | | | Other errors accessing the registers in mv88e6352_serdes_pcs_get_state() print "PHY " before the register name, except for the BMSR. Make this consistent with the other error messages. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: use BMSR_ANEGCOMPLETE bit for filling an_completeMarek Behún2022-06-081-16/+11
| | | | | | | | | | | | | | | | | | Commit ede359d8843a ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN is bypassed") added the ability to link if AN was bypassed, and added filling of state->an_complete field, but set it to true if AN was enabled in BMCR, not when AN was reported complete in BMSR. This was done because for some reason, when I wanted to use BMSR value to infer an_complete, I was looking at BMSR_ANEGCAPABLE bit (which was always 1), instead of BMSR_ANEGCOMPLETE bit. Use BMSR_ANEGCOMPLETE for filling state->an_complete. Fixes: ede359d8843a ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN is bypassed") Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_registerMiaoqian Lin2022-05-271-0/+1
| | | | | | | | | | | | | | | of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak. Fixes: a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: remove port argument from ->change_tag_protocol()Vladimir Oltean2022-05-121-4/+18
| | | | | | | | | | | | | | | | | | | | | | DSA has not supported (and probably will not support in the future either) independent tagging protocols per CPU port. Different switch drivers have different requirements, some may need to replicate some settings for each CPU port, some may need to apply some settings on a single CPU port, while some may have to configure some global settings and then some per-CPU-port settings. In any case, the current model where DSA calls ->change_tag_protocol for each CPU port turns out to be impractical for drivers where there are global things to be done. For example, felix calls dsa_tag_8021q_register(), which makes no sense per CPU port, so it suppresses the second call. Let drivers deal with replication towards all CPU ports, and remove the CPU port argument from the function prototype. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Cosmetic change spaces to tabs in dsa_switch_opsMarek Behún2022-05-011-5/+5
| | | | | | | | | All but 5 methods in dsa_swith_ops use tabs for indentation. Change the 5 methods that break this rule. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: Single chip mode detection for MV88E6*41Nathan Rossi2022-04-281-7/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The mv88e6xxx driver expects switches that are configured in single chip addressing mode to have the MDIO address configured as 0. This is due to the switch ADDR pins representing the single chip addressing mode as 0. However depending on the device (e.g. MV88E6*41) the switch does not respond on address 0 or any other address below 16 (the first port address) in single chip addressing mode. This allows for other devices to be on the same shared MDIO bus despite the switch being in single chip addressing mode. When using a switch that works this way it is not possible to configure switch driver as single chip addressing via device tree, along with another MDIO device on the same bus with address 0, as both devices would have the same address of 0 resulting in mdiobus_register_device -EBUSY errors for one of the devices with address 0. In order to support this configuration the switch node can have its MDIO address configured as 16 (the first address that the device responds to). During initialization the driver will treat this address similar to how address 0 is, however because this address is also a valid multi-chip address (in certain switch models, but not all) the driver will configure the SMI in single chip addressing mode and attempt to detect the switch model. If the device is configured in single chip addressing mode this will succeed and the initialization process can continue. If it fails to detect a valid model this is because the switch model register is not a valid register when in multi-chip mode, it will then fall back to the existing SMI initialization process using the MDIO address as the multi-chip mode address. This detection method is safe if the device is in either mode because the single chip addressing mode read is a direct SMI/MDIO read operation and has no side effects compared to the SMI writes required for the multi-chip addressing mode. In order to implement this change, the reset gpio configuration is moved to occur before any SMI initialization. This ensures that the device has the same/correct reset gpio state for both mv88e6xxx_smi_init calls. Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220427130928.540007-1-nathan@nathanrossi.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Fix port_hidden_wait to account for port_base_addrNathan Rossi2022-04-261-2/+3
| | | | | | | | | | | | | | | | | | | | The other port_hidden functions rely on the port_read/port_write functions to access the hidden control port. These functions apply the offset for port_base_addr where applicable. Update port_hidden_wait to use the port_wait_bit so that port_base_addr offsets are accounted for when waiting for the busy bit to change. Without the offset the port_hidden_wait function would timeout on devices that have a non-zero port_base_addr (e.g. MV88E6141), however devices that have a zero port_base_addr would operate correctly (e.g. MV88E6390). Fixes: 609070133aff ("net: dsa: mv88e6xxx: update code operating on hidden registers") Signed-off-by: Nathan Rossi <nathan@nathanrossi.com> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220425070454.348584-1-nathan@nathanrossi.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: dsa: mv88e6xxx: Fill in STU support for all supported chipsTobias Waldekranz2022-03-211-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | Some chips using the split VTU/STU design will not accept VTU entries who's SID points to an invalid STU entry. Therefore, mark all those chips with either the mv88e6352_g1_stu_* or mv88e6390_g1_stu_* ops as appropriate. Notably, chips for the Opal Plus (6085/6097) era seem to use a different implementation than those from Agate (6352) and onwards, even though their external interface is the same. The former happily accepts VTU entries referencing invalid STU entries, while the latter does not. This fixes an issue where the driver would fail to probe switch trees that contained chips of the Agate/Topaz generation which did not declare STU support, as loaded VTU entries would be read back as invalid. Fixes: 49c98c1dc7d9 ("net: dsa: mv88e6xxx: Disentangle STU from VTU") Reported-by: Marek Behún <kabel@kernel.org> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20220319110345.555270-1-tobias@waldekranz.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Ensure STU support in VLAN MSTI callbackTobias Waldekranz2022-03-211-0/+3
| | | | | | | | | | | | | In the same way that we check for STU support in the MST state callback, we should also verify it before trying to change a VLANs MSTI membership. Fixes: acaf4d2e36b3 ("net: dsa: mv88e6xxx: MST Offloading") Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Require ops be implemented to claim STU supportTobias Waldekranz2022-03-211-1/+3
| | | | | | | | | | | | | | | | | | | Simply having a physical STU table in the device doesn't do us any good if there's no implementation of the relevant ops to access that table. So ensure that chips that claim STU support can also talk to the hardware. This fixes an issue where chips that had a their ->info->max_sid set (due to their family membership), but no implementation (due to their chip-specific ops struct) would fail to probe. Fixes: 49c98c1dc7d9 ("net: dsa: mv88e6xxx: Disentangle STU from VTU") Reported-by: Marek Behún <kabel@kernel.org> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Marek Behún <kabel@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: pass extack to dsa_switch_ops :: port_mirror_add()Vladimir Oltean2022-03-171-1/+2
| | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: MST OffloadingTobias Waldekranz2022-03-172-8/+255
| | | | | | | | Allocate a SID in the STU for each MSTID in use by a bridge and handle the mapping of MSTIDs to VLANs using the SID field of each VTU entry. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Export STU as devlink regionTobias Waldekranz2022-03-172-0/+95
| | | | | | | | | Export the raw STU data in a devlink region so that it can be inspected from userspace and compared to the current bridge configuration. Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: Disentangle STU from VTUTobias Waldekranz2022-03-174-135/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In early LinkStreet silicon (e.g. 6095/6185), the per-VLAN STP states were kept in the VTU - there was no concept of a SID. Later, the information was split into two tables, where the VTU only tracked memberships and deferred the STP state tracking to the STU via a pointer (SID). This meant that a group of VLANs could share the same STU entry. Most likely, this was done to align with MSTP (802.1Q-2018, Clause 13), which is built on this principle. While the VTU is still 4k lines on most devices, the STU is capped at 64 entries. This means that the current stategy, updating STU info whenever a VTU entry is updated, can not easily support MSTP because: - The maximum number of VIDs would also be capped at 64, as we would have to allocate one SID for every VTU entry - even if many VLANs would effectively share the same MST. - MSTP updates would be unnecessarily slow as you would have to iterate over all VLANs that share the same MST. In order to support MSTP offloading in the future, manage the STU as a separate entity from the VTU. Only add support for newer hardware with separate VTU and STU. VTU-only devices can also be supported, but essentially this requires a software implementation of an STU (fanning out state changed to all VLANs tied to the same MST). Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: Use netif_rx().Sebastian Andrzej Siewior2022-03-041-1/+1
| | | | | | | | | | | | | | | | | | | Since commit baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.") the function netif_rx() can be used in preemptible/thread context as well as in interrupt context. Use netif_rx(). Cc: Kurt Kanzenbach <kurt@linutronix.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Vivien Didelot <vivien.didelot@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: Kurt Kanzenbach <kurt@linutronix.de> # hellcreek Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: mv88e6xxx: support RMII cmodeBaruch Siach2022-03-021-0/+3
| | | | | | | | | Add support for direct RMII MAC mode. This allows hardware with CPU port connected in direct 100M fixed link to work properly. Signed-off-by: Baruch Siach <baruch.siach@siklu.com> Link: https://lore.kernel.org/r/a962d1ccbeec42daa10dd8aff0e66e31f0faf1eb.1646050203.git.baruch@tkos.co.il Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: mv88e6xxx: don't error out cmode set on missing laneBaruch Siach2022-03-021-0/+2
| | | | | | | | | | When the given cmode has no serdes, mv88e6xxx_serdes_get_lane() returns -NODEV. Earlier in the same function the code skips serdes handing in this case. Do the same after cmode set. Signed-off-by: Baruch Siach <baruch.siach@siklu.com> Link: https://lore.kernel.org/r/cd95cf3422ae8daf297a01fa9ec3931b203cdf45.1646050203.git.baruch@tkos.co.il Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: pass extack to .port_bridge_join driver methodsVladimir Oltean2022-02-271-2/+4
| | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: request drivers to perform FDB isolationVladimir Oltean2022-02-271-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-02 03:18:08 +0000