- 17 Jul, 2023 18 commits
-
-
Luo Jie authored
qca8081 PHY supports to use genphy_c45_pma_read_abilities for getting the PHY features supported except for the autoneg ability but autoneg ability exists in MDIO_STAT1 instead of MMD7.1, add it manually after calling genphy_c45_pma_read_abilities. Signed-off-by:
Luo Jie <quic_luoj@quicinc.com> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vignesh Viswanathan says: ==================== net: qrtr: Few fixes in QRTR Add fixes in QRTR ns to change server and nodes radix tree to xarray to avoid a use-after-free while iterating through the server or nodes radix tree. Also fix the destination port value for IPCR control buffer on older targets. ==================== Signed-off-by: -
Vignesh Viswanathan authored
The destination port value in the IPCR control buffer on older targets is 0xFFFF. Handle the same by updating the dst_port to QRTR_PORT_CTRL. Signed-off-by:
Vignesh Viswanathan <quic_viswanat@quicinc.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Vignesh Viswanathan authored
There is a use after free scenario while iterating through the nodes radix tree despite the ns being a single threaded process. This can happen when the radix tree APIs are not synchronized with the rcu_read_lock() APIs. Convert the radix tree for nodes to xarray to take advantage of the built in rcu lock usage provided by xarray. Signed-off-by:
Chris Lew <quic_clew@quicinc.com> Signed-off-by:
-
Vignesh Viswanathan authored
There is a use after free scenario while iterating through the servers radix tree despite the ns being a single threaded process. This can happen when the radix tree APIs are not synchronized with the rcu_read_lock() APIs. Convert the radix tree for servers to xarray to take advantage of the built in rcu lock usage provided by xarray. Signed-off-by:
-
David S. Miller authored
Justin Chen says: ==================== Brcm ASP 2.0 Ethernet Controller Add support for the Broadcom ASP 2.0 Ethernet controller which is first introduced with 72165. ==================== Signed-off-by: -
Justin Chen authored
Add maintainers entry for ASP 2.0 Ethernet driver. Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
Justin Chen <justin.chen@broadcom.com> Signed-off-by:
-
Florian Fainelli authored
74165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY, utilize the recently defined 16nm EPHY macro to configure that PHY. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Justin Chen authored
Add mdio compat string for ASP 2.0 ethernet driver. Reviewed-by:
-
Justin Chen authored
Add support for ethernet driver specific stats. Signed-off-by:
-
Justin Chen authored
Add support for eth_mac_stats, rmon_stats, and eth_ctrl_stats. Signed-off-by:
-
Justin Chen authored
Add support for eee mode. Signed-off-by:
-
Justin Chen authored
Add support for wake on network filters. The max match is 256 bytes. Signed-off-by:
-
Justin Chen authored
Add support for Wake-On-Lan magic packet and magic packet with password. Signed-off-by:
-
Justin Chen authored
Add support for the Broadcom ASP 2.0 Ethernet controller which is first introduced with 72165. This controller features two distinct Ethernet ports that can be independently operated. Reviewed-by:
-
Florian Fainelli authored
Add a binding document for the Broadcom ASP 2.0 Ethernet controller. Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Justin Chen authored
The ASP 2.0 Ethernet controller uses a brcm unimac. Reviewed-by:
-
Csókás Bence authored
Rename local `struct fec_enet_private *adapter` to `fep` in `fec_ptp_gettime()` to match the rest of the driver Signed-off-by:
Csókás Bence <csokas.bence@prolan.hu> Reviewed-by:
-
- 14 Jul, 2023 22 commits
-
-
Jesper Dangaard Brouer authored
Spotted this trivial spell mistake while casually reading the google GVE driver code. Signed-off-by:
Jesper Dangaard Brouer <hawk@kernel.org> Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== mlxsw: Manage RIF across PVID changes The mlxsw driver currently makes the assumption that the user applies configuration in a bottom-up manner. Thus netdevices need to be added to the bridge before IP addresses are configured on that bridge or SVI added on top of it. Enslaving a netdevice to another netdevice that already has uppers is in fact forbidden by mlxsw for this reason. Despite this safety, it is rather easy to get into situations where the offloaded configuration is just plain wrong. As an example, take a front panel port, configure an IP address: it gets a RIF. Now enslave the port to the bridge, and the RIF is gone. Remove the port from the bridge again, but the RIF never comes back. There is a number of similar situations, where changing the configuration there and back utterly breaks the offload. The situation is going to be made better by implementing a range of replays and post-hoc offloads. In this patch set, address the ordering issues related to creation of bridge RIFs. Currently, mlxsw has several shortcomings with regards to RIF handling due to PVID changes: - In order to cause RIF for a bridge device to be created, the user is expected first to set PVID, then to add an IP address. The reverse ordering is disallowed, which is not very user-friendly. - When such bridge gets a VLAN upper whose VID was the same as the existing PVID, and this VLAN netdevice gets an IP address, a RIF is created for this netdevice. The new RIF is then assigned to the 802.1Q FID for the given VID. This results in a working configuration. However, then, when the VLAN netdevice is removed again, the RIF for the bridge itself is never reassociated to the PVID. - PVID cannot be changed once the bridge has uppers. Presumably this is because the driver does not manage RIFs properly in face of PVID changes. However, as the previous point shows, it is still possible to get into invalid configurations. This patch set addresses these issues and relaxes some of the ordering requirements that mlxsw had. The patch set proceeds as follows: - In patch #1, pass extack to mlxsw_sp_br_ban_rif_pvid_change() - To relax ordering between setting PVID and adding an IP address to a bridge, mlxsw must be able to request that a RIF is created with a given VLAN ID, instead of trying to deduce it from the current netdevice settings, which do not reflect the user-requested values yet. This is done in patches #2 and #3. - Similarly, mlxsw_sp_inetaddr_bridge_event() will need to make decisions based on the user-requested value of PVID, not the current value. Thus in patches #4 and #5, add a new argument which carries the requested PVID value. - Finally in patch #6 relax the ban on PVID changes when a bridge has uppers. Instead, add the logic necessary for creation of a RIF as a result of PVID change. - Relevant selftests are presented afterwards. In patch #7 a preparatory helper is added to lib.sh. Patches #8, #9, #10 and #11 include selftests themselves. ==================== Signed-off-by: -
Petr Machata authored
This tests whether addition and deletion of a VLAN upper that coincides with the current PVID setting throws off forwarding. This selftests is specifically geared towards offloading drivers. In particular, mlxsw used to fail this selftest, and an earlier patch in this patchset fixes the issue. However, there's nothing HW-specific in the test itself (it absolutely is supposed to pass on SW datapath), and therefore it is put into the generic forwarding directory. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Danielle Ratson <danieller@nvidia.com> Signed-off-by:
-
Petr Machata authored
This tests whether changes to PVID that coincide with an existing VLAN upper throw off forwarding. This selftests is specifically geared towards offloading drivers, but since there's nothing HW-specific in the test itself (it absolutely is supposed to pass on SW datapath), it is put into the generic forwarding directory. Signed-off-by:
-
Petr Machata authored
Add an alternative path involving VLAN 777 instead of the current 555. Then add tests that verify that marking 777 as PVID makes the 555 path not work, and the 777 path work. Signed-off-by:
-
Petr Machata authored
This test relies on PVID being configured on the bridge itself. Thus when it is deconfigured, the system should lose the ability to forward traffic. Later when it is added again, the ability to forward traffic should be regained. Add tests to exercise these configuration changes and verify results. Signed-off-by:
-
Petr Machata authored
Add two helpers to run a ping test that succeeds when the pings themselves fail. Signed-off-by:
-
Petr Machata authored
Currently, mlxsw has several shortcomings with regards to RIF handling due to PVID changes: - In order to cause RIF for a bridge device to be created, the user is expected first to set PVID, then to add an IP address. The reverse ordering is disallowed, which is not very user-friendly. - When such bridge gets a VLAN upper whose VID was the same as the existing PVID, and this VLAN netdevice gets an IP address, a RIF is created for this netdevice. The new RIF is then assigned to the 802.1Q FID for the given VID. This results in a working configuration. However, then, when the VLAN netdevice is removed again, the RIF for the bridge itself is never reassociated to the VLAN. - PVID cannot be changed once the bridge has uppers. Presumably this is because the driver does not manage RIFs properly in face of PVID changes. However, as the previous point shows, it is still possible to get into invalid configurations. In this patch, add the logic necessary for creation of a RIF as a result of PVID change. Moreover, when a VLAN upper is created whose VID matches lower PVID, do not create RIF for this netdevice. These changes obviate the need for ordering of IP address additions and PVID configuration, so stop forbidding addition of an IP address to a PVID-less bridge. Instead, bail out quietly. Also stop preventing PVID changes when the bridge has uppers. Signed-off-by:
-
Petr Machata authored
For purposes of replay, mlxsw_sp_inetaddr_bridge_event() will need to make decisions based on the proposed value of PVID. Querying PVID reveals the current settings, not the in-flight values that the user requested and that the notifiers are acting upon. Add a parameter, lower_pvid, which carries the proposed PVID of the lower bridge, or -1 if the lower is not a bridge. Signed-off-by:
-
Petr Machata authored
The bridge branch of the dispatch in this function is going to get more code and will need curly braces. Per the doctrine, that means the whole if-else chain should get them. Signed-off-by:
-
Petr Machata authored
Currently, when an IP address is added to a bridge that has no PVID, the operation is rejected. An IP address addition is interpreted as a request to create a RIF for the bridge device, but without a PVID there is no VLAN for which the RIF should be created. Thus the correct way to create a RIF for a bridge as a user is to first add a PVID, and then add the IP address. Ideally this ordering requirement would not exist. RIF would be created either because an IP address is added, or because a PVID is added, depending on which comes last. For that, the switchdev code (which notices the PVID change request) must be able to request that a RIF is created with a given VLAN ID, because at the time that the PVID notification is distributed, the PVID setting is not yet visible for querying. Therefore when creating a VLAN-based RIF, use mlxsw_sp_rif_params.vid to communicate the VID, and do not determine it ad-hoc in the fid_get callback. Signed-off-by:
-
Petr Machata authored
The fid_get callback is called to allocate a FID for the newly-created RIF. In a following patch, the fid_get implementation for VLANs will be modified to take the VLAN ID from the parameters instead of deducing it from the netdevice. To that end, propagate the RIF parameters to the fid_get callback. Signed-off-by:
-
Petr Machata authored
Currently the reason for rejection of PVID manipulation is dumped to syslog, and a generic -EBUSY is returned to the userspace. But switchdev_handle_port_obj_add(), through which we get to mlxsw_sp_port_vlans_add(), handles extack just fine, and we can pass the message this way. This improves visibility into reasons why the request to change PVID was rejected. Before the change: # bridge vlan add dev br vid 2 self pvid untagged RTNETLINK answers: Device or resource busy (plus a syslog line) After the change: # bridge vlan add dev br vid 2 self pvid untagged Error: mlxsw_spectrum: Can't change PVID, it's used by router interface. Note that this particular error message is going away in the following patches. However the ability to pass error messages through extack will be useful more broadly for communicating in particular reasons why a RIF failed to be created. Signed-off-by:
-
David S. Miller authored
Sabrina Dubroca says: ==================== net: add MACsec offload selftests Patch 1 adds MACsec offload to netdevsim (unchanged from v2). Patch 2 adds a corresponding selftest to the rtnetlink testsuite. ==================== Signed-off-by: -
Sabrina Dubroca authored
Like the IPsec offload test, this requires netdevsim. Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
-
Sabrina Dubroca authored
When the kernel is compiled with MACsec support, add the NETIF_F_HW_MACSEC feature to netdevsim devices and implement macsec_ops. To allow easy testing of failure from the device, support is limited to 3 SecY's per netdevsim device, and 1 RXSC per SecY. v2: - nsim_macsec_add_secy, return -ENOSPC if secy_count isn't full but we can't find an empty slot (Simon Horman) - add sci_to_cpu to make sparse happy (Simon Horman) - remove set but not used secy variable (kernel test robot and Simon Horman) Signed-off-by:
-
Jiri Pirko authored
The checks in question were introduced by: commit 6b4db2e5 ("devlink: Fix use-after-free after a failed reload"). That fixed an issue of reload with mlxsw driver. Back then, that was a valid fix, because there was a limitation in place that prevented drivers from registering/unregistering params when devlink instance was registered. It was possible to do the fix differently by changing drivers to register/unregister params in appropriate places making sure the ops operate only on memory which is allocated and initialized. But that, as a dependency, would require to remove the limitation mentioned above. Eventually, this limitation was lifted by: commit 1d18bb1a ("devlink: allow registering parameters after the instance") Also, the alternative fix (which also fixed another issue) was done by: commit 74cbc3c0 ("mlxsw: spectrum_acl_tcam: Move devlink param to TCAM code"). Therefore, the checks are no longer relevant. Each driver should make sure to have the params registered only when the memory the ops are working with is allocated and initialized. So remove the checks. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== Convert mv88e6xxx to phylink_pcs This series (previously posted with further patches on the 26 June as RFC) converts mv88e6xxx to phylink_pcs, and thus moves it from being a pre-March 2020 legacy driver. The first four patches lay the ground-work for the conversion by adding four new methods to the phylink_pcs operations structure: pcs_enable() - called when the PCS is going to start to be used pcs_disable() - called when the PCS is no longer being used pcs_pre_config() - called before the MAC configuration method pcs_post_config() - called after the MAC configuration method Both of these are necessary for some of the mv88e639x workarounds. We also add the ability to inform phylink of a change to the PCS state without involving the MAC later, by providing phylink_pcs_change() which takes a phylink_pcs structure rather than a phylink structure. phylink maintains which instance the PCS is conencted to, so internally it can do the right thing when the PCS is in-use. Then we provide some additional mdiobus and mdiodev accessors that we will be using in the new PCS drivers. The changes for mv88e6xxx follow, and the first one needs to be explicitly pointed out - we (Andrew and myself) have both decided that all possible approaches to maintaining backwards compatibility with DT have been exhaused - everyone has some objection to everything that has been proposed. So, after many years of trying, we have decided that this is just an impossibility, and with this patch, we are now intentionally and knowingly breaking any DT that does not specify the CPU and DSA port fixed-link parameters. Hence why Andrew has recently been submitting DT update patches. It is regrettable that it has come to this. Following this, we start preparing 88e6xxx for phylink_pcs conversion by padding the mac_select_pcs() DSA method, and the internal hooks to create and tear-down PCS instances. Rather than bloat the already very large mv88e6xxx_ops structure, I decided that it would be better that the new internal chip specific PCS methods are all grouped within their own structure - and this structure can be declared in the PCS drivers themselves. Then we have the actual conversion patches, one for each family of PCS. Lastly, we clean up the driver after conversion, removing all the now redundant code. ==================== Signed-off-by: -
Russell King (Oracle) authored
Now that mv88e6xxx is completely converted to using phylink_pcs support, we have no need for the serdes methods. Remove all this infrastructure. Also remove the __maybe_unused from mv88e6xxx_pcs_select(). Signed-off-by:
-
Russell King (Oracle) authored
Convert the 88E6390, 88E6390X, and 88E6393X family of switches to use the phylink_pcs infrastructure. Signed-off-by:
-
Russell King authored
Convert the 88E6352 SERDES code to use the phylink_pcs infrastructure. Signed-off-by:
-
Russell King (Oracle) authored
Convert the 88E6185 SERDES code to use the phylink_pcs infrastructure. Reviewed-by:
-
