summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-10-08wifi: ipw2x00/lib80211: move remaining lib80211 into libipwJohannes Berg
There's already much code in libipw that used to be shared with more drivers, but now with the prior cleanups, those old Intel ipw2x00 drivers are also the only ones using whatever is now left of lib80211. Move lib80211 entirely into libipw. Link: https://patch.msgid.link/20241007202707.915ef7b9e7c7.Ib9876d2fe3c90f11d6df458b16d0b7d4bf551a8d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08staging: rtl8192e: delete the driverJohannes Berg
This driver is using lib80211 and any driver that plans to ever leave staging should never have done that, so remove the driver to enable cleaning up lib80211 into libipw inside the old Intel drivers. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20241007202707.d0e59cdd2cdc.I8e4d74a6e1d09eefe1f5e2e208735ba2ccef1d4f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: libertas: don't select/include lib80211Johannes Berg
This isn't used in this driver, and should't be, so remove the include as well as the select. Link: https://patch.msgid.link/20241007202706.f8a6dd67f650.I74bc1f334c02043a238303d3e71c955d0d9b01b0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: mwifiex: don't include lib80211.hJohannes Berg
This really should never have been used, it's ancient code, but then the driver needs its own define for NUM_WEP_KEYS. Link: https://patch.msgid.link/20241007202706.74be9cca3eb8.I47b2e8e2d09c0a0be1f8346478d3d908b4021abd@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: qtnfmac: don't include lib80211.hJohannes Berg
This driver doesn't use it, and really can't, so don't include lib80211.h. Link: https://patch.msgid.link/20241007202706.d92615cbf659.I2dc8ea3df0760121dc202616bdf3942caf51b232@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: nl80211: remove redundant null pointer check in coalescingDmitry Kandybka
In 'cfg80211_free_coalesce', '&coalesce->rules[i]' is a pointer to VLA member of 'struct cfg80211_coalesce' and should never be NULL, so redundant check may be dropped. I think this is correct, but I haven't tested it seriously. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com> Link: https://patch.msgid.link/20241003095912.218465-1-d.kandybka@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08mac80211: Reorganize kerneldoc parameter namesJulia Lawall
Reorganize kerneldoc parameter names to match the parameter order in the function header. Problems identified using Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20240930112121.95324-28-Julia.Lawall@inria.fr Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: cfg80211: check radio iface combination for multi radio per wiphyKarthikeyan Periyasamy
Currently, wiphy_verify_combinations() fails for the multi-radio per wiphy due to the condition check on new global interface combination that DFS only works on one channel. In a multi-radio scenario, new global interface combination encompasses the capabilities of all radio combinations, so it supports more than one channel with DFS. For multi-radio per wiphy, interface combination verification needs to be performed for radio specific interface combinations. This is necessary as the new global interface combination combines the capabilities of all radio combinations. Fixes: a01b1e9f9955 ("wifi: mac80211: add support for DFS with multiple radios") Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Link: https://patch.msgid.link/20240917140239.886083-1-quic_periyasa@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: mac80211, cfg80211: miscellaneous spelling fixesDmitry Antipov
Correct spelling here and there as suggested by codespell. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://patch.msgid.link/20240913084919.118862-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08wifi: mac80211: constify ieee80211_ie_build_{he,eht}_oper() chandefJeff Johnson
The chandef parameter passed to ieee80211_ie_build_he_oper() and ieee80211_ie_build_eht_oper is read-only. Since it is never modified, add the const qualifier to this parameter. This makes these consistent with ieee80211_ie_build_ht_oper() and ieee80211_ie_build_vht_oper(). Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20240910-wireless-utils-constify-v1-1-e59947bcb3c3@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-10-08tools: ynl-gen: refactor check validation for TypeBinaryJakub Kicinski
We only support a single check at a time for TypeBinary. Refactor the code to cover 'exact-len' and make adding new checks easier. Link: https://lore.kernel.org/20241004063855.1a693dd1@kernel.org Link: https://patch.msgid.link/20241007155311.1193382-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08idpf: Don't hard code napi_struct sizeJoe Damato
The sizeof(struct napi_struct) can change. Don't hardcode the size to 400 bytes and instead use "sizeof(struct napi_struct)". Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Joe Damato <jdamato@fastly.com> Acked-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20241004105407.73585-1-jdamato@fastly.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-08Merge branch 'rtnetlink-per-netns-rtnl'Paolo Abeni
Kuniyuki Iwashima says: ==================== rtnetlink: Per-netns RTNL. rtnl_lock() is a "Big Kernel Lock" in the networking slow path and serialised all rtnetlink requests until 4.13. Since RTNL_FLAG_DOIT_UNLOCKED and RTNL_FLAG_DUMP_UNLOCKED have been introduced in 4.14 and 6.9, respectively, rtnetlink message handlers are ready to be converted to RTNL-less/free. 15 out of 44 dumpit()s have been converted to RCU so far, and the progress is pretty good. We can now dump various major network resources without RTNL. 12 out of 87 doit()s have been converted, but most of the converted doit()s are also on the reader side of RTNL; their message types are RTM_GET*. So, most of RTM_(NEW|DEL|SET)* operations are still serialised by RTNL. For example, one of our services creates 2K netns and a small number of network interfaces in each netns that require too many writer-side rtnetlink requests, and setting up a single host takes 10+ minutes. RTNL is still a huge pain for network configuration paths, and we need more granular locking, given converting all doit()s would be unfeasible. Actually, most RTNL users do not need to freeze multiple netns, and such users can be protected by per-netns RTNL mutex. The exceptions would be RTM_NEWLINK, RTM_DELLINK, and RTM_SETLINK. (See [0] and [1]) This series is the first step of the per-netns RTNL conversion that gradually replaces rtnl_lock() with rtnl_net_lock(net) under CONFIG_DEBUG_NET_SMALL_RTNL. [0]: https://netdev.bots.linux.dev/netconf/2024/index.html [1]: https://lpc.events/event/18/contributions/1959/ ==================== Link: https://patch.msgid.link/20241004221031.77743-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08rtnetlink: Add ASSERT_RTNL_NET() placeholder for netdev notifier.Kuniyuki Iwashima
The global and per-netns netdev notifier depend on RTNL, and its dependency is not so clear due to nested calls. Let's add a placeholder to place ASSERT_RTNL_NET() for each event. Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08rtnetlink: Add assertion helpers for per-netns RTNL.Kuniyuki Iwashima
Once an RTNL scope is converted with rtnl_net_lock(), we will replace RTNL helper functions inside the scope with the following per-netns alternatives: ASSERT_RTNL() -> ASSERT_RTNL_NET(net) rcu_dereference_rtnl(p) -> rcu_dereference_rtnl_net(net, p) Note that the per-netns helpers are equivalent to the conventional helpers unless CONFIG_DEBUG_NET_SMALL_RTNL is enabled. Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08rtnetlink: Add per-netns RTNL.Kuniyuki Iwashima
The goal is to break RTNL down into per-netns mutex. This patch adds per-netns mutex and its helper functions, rtnl_net_lock() and rtnl_net_unlock(). rtnl_net_lock() acquires the global RTNL and per-netns RTNL mutex, and rtnl_net_unlock() releases them. We will replace 800+ rtnl_lock() with rtnl_net_lock() and finally removes rtnl_lock() in rtnl_net_lock(). When we need to nest per-netns RTNL mutex, we will use __rtnl_net_lock(), and its locking order is defined by rtnl_net_lock_cmp_fn() as follows: 1. init_net is first 2. netns address ascending order Note that the conversion will be done under CONFIG_DEBUG_NET_SMALL_RTNL with LOCKDEP so that we can carefully add the extra mutex without slowing down RTNL operations during conversion. Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08Revert "rtnetlink: add guard for RTNL"Kuniyuki Iwashima
This reverts commit 464eb03c4a7cfb32cb3324249193cf6bb5b35152. Once we have a per-netns RTNL, we won't use guard(rtnl). Also, there's no users for now. $ grep -rnI "guard(rtnl" || true $ Suggested-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/netdev/CANn89i+KoYzUH+VPLdGmLABYf5y4TW0hrM4UAeQQJ9AREty0iw@mail.gmail.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08Merge branch 'net-fec-add-pps-channel-configuration'Paolo Abeni
Francesco Dolcini says: ==================== net: fec: add PPS channel configuration Make the FEC Ethernet PPS channel configurable from device tree. ==================== Link: https://patch.msgid.link/20241004152419.79465-1-francesco@dolcini.it Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: fec: make PPS channel configurableFrancesco Dolcini
Depending on the SoC where the FEC is integrated into the PPS channel might be routed to different timer instances. Make this configurable from the devicetree. When the related DT property is not present fallback to the previous default and use channel 0. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Rafael Beims <rafael.beims@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Csókás, Bence <csokas.bence@prolan.hu> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: fec: refactor PPS channel configurationFrancesco Dolcini
Preparation patch to allow for PPS channel configuration, no functional change intended. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Csókás, Bence <csokas.bence@prolan.hu> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08dt-bindings: net: fec: add pps channel propertyFrancesco Dolcini
Add fsl,pps-channel property to select where to connect the PPS signal. This depends on the internal SoC routing and on the board, for example on the i.MX8 SoC it can be connected to an external pin (using channel 1) or to internal eDMA as DMA request (channel 0). Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08Merge branch 'net-sparx5-prepare-for-lan969x-switch-driver'Paolo Abeni
Daniel Machon says: ==================== net: sparx5: prepare for lan969x switch driver == Description: This series is the first of a multi-part series, that prepares and adds support for the new lan969x switch driver. The upstreaming efforts is split into multiple series (might change a bit as we go along): 1) Prepare the Sparx5 driver for lan969x (this series) 2) Add support lan969x (same basic features as Sparx5 provides + RGMII, excl. FDMA and VCAP) 3) Add support for lan969x FDMA 4) Add support for lan969x VCAP == Lan969x in short: The lan969x Ethernet switch family [1] provides a rich set of switching features and port configurations (up to 30 ports) from 10Mbps to 10Gbps, with support for RGMII, SGMII, QSGMII, USGMII, and USXGMII, ideal for industrial & process automation infrastructure applications, transport, grid automation, power substation automation, and ring & intra-ring topologies. The LAN969x family is hardware and software compatible and scalable supporting 46Gbps to 102Gbps switch bandwidths. == Preparing Sparx5 for lan969x: The lan969x switch chip reuses many of the IP's of the Sparx5 switch chip, therefore it has been decided to add support through the existing Sparx5 driver, in order to avoid a bunch of duplicate code. However, in order to reuse the Sparx5 switch driver, we have to introduce some mechanisms to handle the chip differences that are there. These mechanisms are: - Platform match data to contain all the differences that needs to be handled (constants, ops etc.) - Register macro indirection layer so that we can reuse the existing register macros. - Function for branching out on platform type where required. In some places we ops out functions and in other places we branch on the chip type. Exactly when we choose one over the other, is an estimate in each case. After this series is applied, the Sparx5 driver will be prepared for lan969x and still function exactly as before. == Patch breakdown: Patch #1 adds private match data Patch #2 adds register macro indirection layer Patch #3-#4 does some preparation work Patch #5-#7 adds chip constants and updates the code to use them Patch #8-#13 adds and uses ops for handling functions differently on the two platforms. Patch #14 adds and uses a macro for branching out on the chip type. Patch #15 (NEW) redefines macros for internal ports and PGID's. [1] https://www.microchip.com/en-us/product/lan9698 To: David S. Miller <davem@davemloft.net> To: Eric Dumazet <edumazet@google.com> To: Jakub Kicinski <kuba@kernel.org> To: Paolo Abeni <pabeni@redhat.com> To: Lars Povlsen <lars.povlsen@microchip.com> To: Steen Hegelund <Steen.Hegelund@microchip.com> To: horatiu.vultur@microchip.com To: jensemil.schulzostergaard@microchip.com To: UNGLinuxDriver@microchip.com To: Richard Cochran <richardcochran@gmail.com> To: horms@kernel.org To: justinstitt@google.com To: gal@nvidia.com To: aakash.r.menon@gmail.com To: jacob.e.keller@intel.com To: ast@fiberby.net Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Daniel Machon <daniel.machon@microchip.com> ==================== Link: https://patch.msgid.link/20241004-b4-sparx5-lan969x-switch-driver-v2-0-d3290f581663@microchip.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: redefine internal ports and PGID's as offsetsDaniel Machon
Internal ports and PGID's are both defined relative to the number of front ports on Sparx5. This will not work on lan969x. Instead make them offsets to the number of front ports and add two helpers to retrieve them. Use the helpers throughout. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add is_sparx5 macro and use it throughoutDaniel Machon
We dont want to ops out each time a function needs to do some platform specifics. In particular we have a few places, where it would be convenient to just branch out on the platform type. Add the function is_sparx5() and, initially, use it for: - register writes that should only be done on Sparx5 (QSYS_CAL_CTRL, CLKGEN_LCPLL1_CORE_CLK). - function calls that should only be done on Sparx5 (ethtool_op_get_ts_info()) - register writes that are chip-exclusive (MASK_CFG1/2, PGID_CFG1/2, these are replicated for n_ports >32 on Sparx5). The is_sparx5() function simply checks the target chip type, to determine if this is a Sparx5 SKU or not. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: ops out function for DSM calendar calculationDaniel Machon
The DSM (Disassembler) calendar grants each port access to internal busses. The configuration of the calendar is done differently on Sparx5 and lan969x. Therefore ops out the function that calculates the calendar. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: ops out PTP IRQ handlerDaniel Machon
The PTP registers are located in two different register targets on Sparx5 and lan969x. We can't handle this with the register macros, so ops out the handler. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: ops out function for setting the port muxDaniel Machon
Port muxing is configured based on the supported port modes. As these modes can differ on Sparx5 and lan969x we ops out the port muxing function. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: ops out functions for getting certain array valuesDaniel Machon
Add getters for getting values in arrays: sdlb_groups and sparx5_hsch_max_group_rate and ops out the getters, as these arrays will differ on lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: ops out chip port to device index/bit functionsDaniel Machon
The chip port device index and mode bit can be obtained using the port number. However the mapping of port number to chip device index and mode bit differs on Sparx5 and lan969x. Therefore ops out the function. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add ops to match dataDaniel Machon
Add new struct sparx5_ops, containing functions that needs to be different as the implementation differs on Sparx5 and lan969x. Initially we add functions for checking the port type (2g5, 5g, 10g or 25g) based on the port number. Update the code to use the ops instead of the platform specific functions. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: use SPX5_CONST for constants which do not have a symbolDaniel Machon
Now that we have indentified all the chip constants, update the use of them where a symbol is not defined for the constant. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: use SPX5_CONST for constants which already have a symbolDaniel Machon
Now that we have indentified all the chip constants, update the use of them where a symbol is already defined for the constant. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add constants to match dataDaniel Machon
Add new struct sparx5_consts, containing all the chip constants that are known to be different for Sparx5 and lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add *sparx5 argument to a few functionsDaniel Machon
The *sparx5 context pointer is required in functions that need to access platform constants (which will be added in a subsequent patch). Prepare for this by updating the prototype and use of such functions. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: modify SPX5_PORTS_ALL macroDaniel Machon
In preparation for lan969x, we need to define the SPX5_PORTS_ALL macro as 70 (65 front ports + 5 internal ports). This is required as the SPX5_PORT_CPU will be redefined as an offset to the number of front ports, in a subsequent patch. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add indirection layer to register macrosDaniel Machon
The register macros are used to read and write to the switch registers. The registers are largely the same on Sparx5 and lan969x, however in some cases they differ. The differences can be one or more of the following: target size, register address, register count, group address, group count, group size, field position, field size. In order to handle these differences, we introduce a new indirection layer, that defines and maps them to corresponding values, based on the platform. As the register macro arguments can now be non-constants, we also add non-constant variants of FIELD_GET and FIELD_PREP. Since the indirection layer contributes to longer macros, we have changed the formatting of them slightly, to adhere to a 80 character limit, and added a comment if a macro is platform-specific. With these additions, we can reuse all the existing macros for lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: sparx5: add support for private match dataDaniel Machon
In preparation for lan969x, add support for private match data. This will be needed for abstracting away differences between the Sparx5 and lan969x platforms. We initially add values for: iomap, iomap size and ioranges. Update the use of these throughout. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08Documentation: networking: add Twisted Pair Ethernet diagnostics at OSI Layer 1Oleksij Rempel
This patch introduces a diagnostic guide for troubleshooting Twisted Pair Ethernet variants at OSI Layer 1. It provides detailed steps for detecting and resolving common link issues, such as incorrect wiring, cable damage, and power delivery problems. The guide also includes interface verification steps and PHY-specific diagnostics. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20241004121824.1716303-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08Merge branch 'net-phy-support-master-slave-config-via-device-tree'Paolo Abeni
Oleksij Rempel says: ==================== net: phy: Support master-slave config via device tree This patch series adds support for configuring the master/slave role of PHYs via the device tree. A new `master-slave` property is introduced in the device tree bindings, allowing PHYs to be forced into either master or slave mode. This is particularly necessary for Single Pair Ethernet (SPE) PHYs (1000/100/10Base-T1), where hardware strap pins may not be available or correctly configured, but it is applicable to all PHY types. changes v5: - sync DT options with ethtool nameing. changes v4: - add Reviewed-by - rebase against latest net-next changes v3: - rename master-slave to timing-role - add prefer-master/slave support ==================== Link: https://patch.msgid.link/20241004090100.1654353-1-o.rempel@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: phy: Add support for PHY timing-role configuration via device treeOleksij Rempel
Introduce support for configuring the master/slave role of PHYs based on the `timing-role` property in the device tree. While this functionality is necessary for Single Pair Ethernet (SPE) PHYs (1000/100/10Base-T1) where hardware strap pins may be unavailable or incorrectly set, it works for any PHY type. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Divya Koppera <divya.koppera@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08dt-bindings: net: ethernet-phy: Add timing-role role property for ethernet PHYsOleksij Rempel
This patch introduces a new `timing-role` property in the device tree bindings for configuring the master/slave role of PHYs. This is essential for scenarios where hardware strap pins are unavailable or incorrectly configured. The `timing-role` property supports the following values: - `forced-master`: Forces the PHY to operate as a master (clock source). - `forced-slave`: Forces the PHY to operate as a slave (clock receiver). - `preferred-master`: Prefers the PHY to be master but allows negotiation. - `preferred-slave`: Prefers the PHY to be slave but allows negotiation. The terms "master" and "slave" are retained in this context to align with the IEEE 802.3 standards, where they are used to describe the roles of PHY devices in managing clock signals for data transmission. In particular, the terms are used in specifications for 1000Base-T and MultiGBASE-T PHYs, among others. Although there is an effort to adopt more inclusive terminology, replacing these terms could create discrepancies between the Linux kernel and the established standards, documentation, and existing hardware interfaces. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Divya Koppera <divya.koppera@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-08net: qcom/emac: Find sgmii_ops by device_for_each_child()Zijun Hu
To prepare for constifying the following old driver core API: struct device *device_find_child(struct device *dev, void *data, int (*match)(struct device *dev, void *data)); to new: struct device *device_find_child(struct device *dev, const void *data, int (*match)(struct device *dev, const void *data)); The new API does not allow its match function (*match)() to modify caller's match data @*data, but emac_sgmii_acpi_match(), as the old API's match function, indeed modifies relevant match data, so it is not suitable for the new API any more, solved by implementing the same finding sgmii_ops function by correcting the function and using it as parameter of device_for_each_child() instead of device_find_child(). By the way, this commit does not change any existing logic. Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://patch.msgid.link/20241003-qcom_emac_fix-v6-1-0658e3792ca4@quicinc.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-07net: phy: mxl-gpy: add missing support for TRIGGER_NETDEV_LINK_10Daniel Golle
The PHY also support 10MBit/s links as well as the corresponding link indication trigger to be offloaded. Add TRIGGER_NETDEV_LINK_10 to the supported triggers. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/cc5da0a989af8b0d49d823656d88053c4de2ab98.1728057367.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07vmxnet3: support higher link speeds from vmxnet3 v9Ronak Doshi
Until now, vmxnet3 was default reporting 10Gbps as link speed. Vmxnet3 v9 adds support for user to configure higher link speeds. User can configure the link speed via VMs advanced parameters options in VCenter. This speed is reported in gbps by hypervisor. This patch adds support for vmxnet3 to report higher link speeds and converts it to mbps as expected by Linux stack. Signed-off-by: Ronak Doshi <ronak.doshi@broadcom.com> Acked-by: Guolin Yang <guolin.yang@broadcom.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241004174303.5370-1-ronak.doshi@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07dt-bindings: net: realtek: Use proper node namesLinus Walleij
We eventually want to get to a place where we fix all DTS files so that we can simply disallow switch/port/ports without the ethernet-* prefix so the DTS files are more readable. Replace: - switch with ethernet-switch - ports with ethernet-ports - port with ethernet-port Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20241004-realtek-bindings-fixup-v2-1-667afa08d184@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07Merge branch 'ipv4-preliminary-work-for-per-netns-rtnl'Jakub Kicinski
Eric Dumazet says: ==================== ipv4: preliminary work for per-netns RTNL Inspired by 9b8ca04854fd ("ipv4: avoid quadratic behavior in FIB insertion of common address") and per-netns RTNL conversion started by Kuniyuki this week. ip_fib_check_default() can use RCU instead of a shared spinlock. fib_info_lock can be removed, RTNL is already used. fib_info_devhash[] can be removed in favor of a single pointer in net_device. ==================== Link: https://patch.msgid.link/20241004134720.579244-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07ipv4: remove fib_info_devhash[]Eric Dumazet
Upcoming per-netns RTNL conversion needs to get rid of shared hash tables. fib_info_devhash[] is one of them. It is unclear why we used a hash table, because a single hlist_head per net device was cheaper and scalable. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241004134720.579244-5-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07ipv4: remove fib_info_lockEric Dumazet
After the prior patch, fib_info_lock became redundant because all of its users are holding RTNL. BH protection is not needed. Remove the READ_ONCE()/WRITE_ONCE() annotations around fib_info_cnt, since it is protected by RTNL. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241004134720.579244-4-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07ipv4: use rcu in ip_fib_check_default()Eric Dumazet
fib_info_devhash[] is not resized in fib_info_hash_move(). fib_nh structs are already freed after an rcu grace period. This will allow to remove fib_info_lock in the following patch. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241004134720.579244-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-07ipv4: remove fib_devindex_hashfn()Eric Dumazet
fib_devindex_hashfn() converts a 32bit ifindex value to a 8bit hash. It makes no sense doing this from fib_info_hashfn() and fib_find_info_nh(). It is better to keep as many bits as possible to let fib_info_hashfn_result() have better spread. Only fib_info_devhash_bucket() needs to make this operation, we can 'inline' trivial fib_devindex_hashfn() in it. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241004134720.579244-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-28 17:09:06 +0000