summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-01-15net: devmem: add ring parameter filteringTaehee Yoo
If driver doesn't support ring parameter or tcp-data-split configuration is not sufficient, the devmem should not be set up. Before setup the devmem, tcp-data-split should be ON and hds-thresh value should be 0. Tested-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Mina Almasry <almasrymina@google.com> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-4-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: ethtool: add support for configuring hds-threshTaehee Yoo
The hds-thresh option configures the threshold value of the header-data-split. If a received packet size is larger than this threshold value, a packet will be split into header and payload. The header indicates TCP and UDP header, but it depends on driver spec. The bnxt_en driver supports HDS(Header-Data-Split) configuration at FW level, affecting TCP and UDP too. So, If hds-thresh is set, it affects UDP and TCP packets. Example: # ethtool -G <interface name> hds-thresh <value> # ethtool -G enp14s0f0np0 tcp-data-split on hds-thresh 256 # ethtool -g enp14s0f0np0 Ring parameters for enp14s0f0np0: Pre-set maximums: ... HDS thresh: 1023 Current hardware settings: ... TCP data split: on HDS thresh: 256 The default/min/max values are not defined in the ethtool so the drivers should define themself. The 0 value means that all TCP/UDP packets' header and payload will be split. Tested-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-3-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: ethtool: add hds_config member in ethtool_netdev_stateTaehee Yoo
When tcp-data-split is UNKNOWN mode, drivers arbitrarily handle it. For example, bnxt_en driver automatically enables if at least one of LRO/GRO/JUMBO is enabled. If tcp-data-split is UNKNOWN and LRO is enabled, a driver returns ENABLES of tcp-data-split, not UNKNOWN. So, `ethtool -g eth0` shows tcp-data-split is enabled. The problem is in the setting situation. In the ethnl_set_rings(), it first calls get_ringparam() to get the current driver's config. At that moment, if driver's tcp-data-split config is UNKNOWN, it returns ENABLE if LRO/GRO/JUMBO is enabled. Then, it sets values from the user and driver's current config to kernel_ethtool_ringparam. Last it calls .set_ringparam(). The driver, especially bnxt_en driver receives ETHTOOL_TCP_DATA_SPLIT_ENABLED. But it can't distinguish whether it is set by the user or just the current config. When user updates ring parameter, the new hds_config value is updated and current hds_config value is stored to old_hdsconfig. Driver's .set_ringparam() callback can distinguish a passed tcp-data-split value is came from user explicitly. If .set_ringparam() is failed, hds_config is rollbacked immediately. Suggested-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Taehee Yoo <ap420073@gmail.com> Link: https://patch.msgid.link/20250114142852.3364986-2-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: loopback: Hold rtnl_net_lock() in blackhole_netdev_init().Kuniyuki Iwashima
blackhole_netdev is the global device in init_net. Let's hold rtnl_net_lock(&init_net) in blackhole_netdev_init(). While at it, the unnecessary dev_net_set() call is removed, which is done in alloc_netdev_mqs(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250114081352.47404-1-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests/net/forwarding: teamd command not foundAlessandro Zanni
Running "make kselftest TARGETS=net/forwarding" results in multiple ccurrences of the same error: - ./lib.sh: line 787: teamd: command not found This patch adds the variable $REQUIRE_TEAMD in every test that uses the command teamd and checks the $REQUIRE_TEAMD variable in the file "lib.sh" to skip the test if the command is not installed. Signed-off-by: Alessandro Zanni <alessandro.zanni87@gmail.com> Link: https://patch.msgid.link/20250114003323.97207-1-alessandro.zanni87@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15Merge branch 'eth-fbnic-add-hardware-monitoring-support'Jakub Kicinski
Sanman Pradhan says: ==================== eth: fbnic: Add hardware monitoring support This patch series adds hardware monitoring support to the fbnic driver. It implements support for reading temperature and voltage sensors via firmware requests, and exposes this data through the HWMON interface. The series is structured as follows: Patch 1: Adds completion infrastructure for firmware requests Patch 2: Implements TSENE sensor message handling Patch 3: Adds HWMON interface support Output: $ ls -l /sys/class/hwmon/hwmon1/ total 0 lrwxrwxrwx 1 root root 0 Sep 10 00:00 device -> ../../../0000:01:00.0 -r--r--r-- 1 root root 4096 Sep 10 00:00 in0_input -r--r--r-- 1 root root 4096 Sep 10 00:00 name lrwxrwxrwx 1 root root 0 Sep 10 00:00 subsystem -> ../../../../../../class/hwmon -r--r--r-- 1 root root 4096 Sep 10 00:00 temp1_input -rw-r--r-- 1 root root 4096 Sep 10 00:00 uevent $ cat /sys/class/hwmon/hwmon1/temp1_input 40480 $ cat /sys/class/hwmon/hwmon1/in0_input 750 ==================== Link: https://patch.msgid.link/20250114000705.2081288-1-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15eth: fbnic: Add hardware monitoring support via HWMON interfaceSanman Pradhan
This patch adds support for hardware monitoring to the fbnic driver, allowing for temperature and voltage sensor data to be exposed to userspace via the HWMON interface. The driver registers a HWMON device and provides callbacks for reading sensor data, enabling system admins to monitor the health and operating conditions of fbnic. Signed-off-by: Sanman Pradhan <sanman.p211993@gmail.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250114000705.2081288-4-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15eth: fbnic: hwmon: Add support for reading temperature and voltage sensorsSanman Pradhan
Add support for reading temperature and voltage sensor data from firmware by implementing a new TSENE message type and response parsing. This adds message handler infrastructure to transmit sensor read requests and parse responses. The sensor data will be exposed through the driver's hwmon interface. Signed-off-by: Sanman Pradhan <sanman.p211993@gmail.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250114000705.2081288-3-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15eth: fbnic: hwmon: Add completion infrastructure for firmware requestsSanman Pradhan
Add infrastructure to support firmware request/response handling with completions. Add a completion structure to track message state including message type for matching, completion for waiting for response, and result for error propagation. Use existing spinlock to protect the writes. The data from the various response types will be added to the "union u" by subsequent commits. Signed-off-by: Sanman Pradhan <sanman.p211993@gmail.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250114000705.2081288-2-sanman.p211993@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15Merge branch 'net-lan969x-add-fdma-support'Jakub Kicinski
Daniel Machon says: ==================== net: lan969x: add FDMA support == Description: This series is the last of a multi-part series, that prepares and adds support for the new lan969x switch driver. The upstreaming efforts has been split into multiple series: 1) Prepare the Sparx5 driver for lan969x (merged) 2) Add support for lan969x (same basic features as Sparx5 provides excl. FDMA and VCAP, merged). 3) Add lan969x VCAP functionality (merged). 4) Add RGMII support (merged). --> 5) Add FDMA support. == FDMA support: The lan969x switch device uses the same FDMA engine as the Sparx5 switch device, with the same number of channels etc. This means we can utilize the newly added FDMA library, that is already in use by the lan966x and sparx5 drivers. As previous lan969x series, the FDMA implementation will hook into the Sparx5 implementation where possible, however both RX and TX handling will be done differently on lan969x and therefore requires a separate implementation of the RX and TX path. Details are in the commit description of the individual patches == Patch breakdown: Patch #1: Enable FDMA support on lan969x Patch #2: Split start()/stop() functions Patch #3: Activate TX FDMA in start() Patch #4: Ops out a few functions that differ on the two platforms Patch #5: Add FDMA implementation for lan969x v1: https://lore.kernel.org/20250109-sparx5-lan969x-switch-driver-5-v1-0-13d6d8451e63@microchip.com ==================== Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-0-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: lan969x: add FDMA implementationDaniel Machon
The lan969x switch device supports manual frame injection and extraction to and from the switch core, using a number of injection and extraction queues. This technique is currently supported, but delivers poor performance compared to Frame DMA (FDMA). This lan969x implementation of FDMA, hooks into the existing FDMA for Sparx5, but requires its own RX and TX handling, as lan969x does not support the same native cache coherency that Sparx5 does. Effectively, this means that we are going to use the DMA mapping API for mapping and unmapping TX buffers. The RX loop will utilize the page pool API for efficient RX handling. Other than that, the implementation is largely the same, and utilizes the FDMA library for DCB and DB handling. Some numbers: Manual injection/extraction (before this series): // iperf3 -c 1.0.1.1 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.02 sec 345 MBytes 289 Mbits/sec sender [ 5] 0.00-10.06 sec 345 MBytes 288 Mbits/sec receiver FDMA (after this series): // iperf3 -c 1.0.1.1 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.03 sec 1.10 GBytes 940 Mbits/sec sender [ 5] 0.00-10.07 sec 1.10 GBytes 936 Mbits/sec receiver Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-5-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: ops out certain FDMA functionsDaniel Machon
We are going to implement the RX and TX paths a bit differently on lan969x and therefore need to introduce new ops for FDMA functions: init, deinit, xmit and poll. Assign the Sparx5 equivalents for these and update the code throughout. Also add a 'struct net_device' argument to the xmit() function, as we will be needing that for lan969x. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-4-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: activate FDMA tx in start()Daniel Machon
The function sparx5_fdma_tx_activate() is responsible for configuring the TX FDMA instance and activating the channel. TX activation has previously been done in the xmit() function, when the first frame is transmitted. Now that we have separate functions for starting and stopping the FDMA, it seems reasonable to move the TX activation to the start function. This change has no implications on the functionality. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-3-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: split sparx5_fdma_{start(),stop()}Daniel Machon
The two functions: sparx5_fdma_{start(),stop()} are responsible for a number of things, namely: allocation and initialization of FDMA buffers, activation FDMA channels in hardware and activation of the NAPI instance. This patch splits the buffer allocation and initialization into init and deinit functions, and the channel and NAPI activation into start and stop functions. This serves two purposes: 1) the start() and stop() functions can be reused for lan969x and 2) prepares for future MTU change support, where we must be able to stop and start the FDMA channels and NAPI instance, without free'ing and reallocating the FDMA buffers. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-2-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: sparx5: enable FDMA on lan969xDaniel Machon
In a previous series, we made sure that FDMA was not initialized and started on lan969x. Now that we are going to support it, undo that change. In addition, make sure the chip ID check is only applicable on Sparx5, as this is a check that is only relevant on this platform. Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Link: https://patch.msgid.link/20250113-sparx5-lan969x-switch-driver-5-v2-1-c468f02fd623@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15hwmon: (ltc2991) Fix mixed signed/unsigned in DIV_ROUND_CLOSESTDavid Lechner
Fix use of DIV_ROUND_CLOSEST where a possibly negative value is divided by an unsigned type by casting the unsigned type to the signed type of the same size (st->r_sense_uohm[channel] has type of u32). The docs on the DIV_ROUND_CLOSEST macro explain that dividing a negative value by an unsigned type is undefined behavior. The actual behavior is that it converts both values to unsigned before doing the division, for example: int ret = DIV_ROUND_CLOSEST(-100, 3U); results in ret == 1431655732 instead of -33. Fixes: 2b9ea4262ae9 ("hwmon: Add driver for ltc2991") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20250115-hwmon-ltc2991-fix-div-round-closest-v1-1-b4929667e457@baylibre.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-01-15bpf: Send signals asynchronously if !preemptiblePuranjay Mohan
BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`. Reported-by: syzbot+97da3d7e0112d59971de@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/67486b09.050a0220.253251.0084.GAE@google.com/ Fixes: 1bc7896e9ef4 ("bpf: Fix deadlock with rq_lock in bpf_send_signal()") Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250115103647.38487-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-01-15power: supply: max17042: add max77705 fuel gauge supportDzmitry Sankouski
Add max77705 fuel gauge support. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-5-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15dt-bindings: power: supply: max17042: add max77705 supportDzmitry Sankouski
Add max77705 fuel gauge support. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-2-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: add undervoltage health status propertyDzmitry Sankouski
Add POWER_SUPPLY_HEALTH_UNDERVOLTAGE status for power supply to report under voltage lockout failures. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250108-starqltechn_integration_upstream-v14-1-f6e84ec20d96@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15sparc/PCI: Update reference to devm_of_pci_get_host_bridge_resources()Bjorn Helgaas
5bd51b35c7cb ("PCI: Rework of_pci_get_host_bridge_resources() to devm_of_pci_get_host_bridge_resources()") converted and renamed of_pci_get_host_bridge_resources(). Update the comment reference to match. Link: https://lore.kernel.org/r/20250113231557.441289-5-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Acked-by: Andreas Larsson <andreas@gaisler.com>
2025-01-15net: ethernet: xgbe: re-add aneg to supported features in PHY quirksHeiner Kallweit
In 4.19, before the switch to linkmode bitmaps, PHY_GBIT_FEATURES included feature bits for aneg and TP/MII ports. SUPPORTED_TP | \ SUPPORTED_MII) SUPPORTED_10baseT_Full) SUPPORTED_100baseT_Full) SUPPORTED_1000baseT_Full) PHY_100BT_FEATURES | \ PHY_DEFAULT_FEATURES) PHY_1000BT_FEATURES) Referenced commit expanded PHY_GBIT_FEATURES, silently removing PHY_DEFAULT_FEATURES. The removed part can be re-added by using the new PHY_GBIT_FEATURES definition. Not clear to me is why nobody seems to have noticed this issue. I stumbled across this when checking what it takes to make phy_10_100_features_array et al private to phylib. Fixes: d0939c26c53a ("net: ethernet: xgbe: expand PHY_GBIT_FEAUTRES") Cc: stable@vger.kernel.org Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/46521973-7738-4157-9f5e-0bb6f694acba@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15PCI: of: Simplify devm_of_pci_get_host_bridge_resources() interfaceBjorn Helgaas
Previously pci_parse_request_of_pci_ranges() supplied the default bus range to devm_of_pci_get_host_bridge_resources(), but that function is static and has no other callers, so there's no reason to complicate its interface by passing the default bus range. Drop the busno and bus_max parameters and use 0x0 and 0xff directly in devm_of_pci_get_host_bridge_resources(). Link: https://lore.kernel.org/r/20250113231557.441289-4-helgaas@kernel.org [bhelgaas: dev_warn() for invalid end of bus-range] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2025-01-15PCI: of: Drop 'No bus range found' messageBjorn Helgaas
The typical bus range for a host bridge is [bus 00-ff], and devm_of_pci_get_host_bridge_resources() defaults to that unless DT contains a "bus-range" property. devm_of_pci_get_host_bridge_resources() previously emitted a message when there was no "bus-range" property, but that seems unnecessary for this common situation. Remove the message. Link: https://lore.kernel.org/r/20250113231557.441289-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2025-01-15PCI: Unexport of_pci_parse_bus_range()Bjorn Helgaas
of_pci_parse_bus_range() is only used in drivers/pci/of.c, so make it static and unexport it. Link: https://lore.kernel.org/r/20250113231557.441289-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
2025-01-15Merge branch 'net-phylink-fix-pcs-without-autoneg'Jakub Kicinski
Russell King says: ==================== net: phylink: fix PCS without autoneg Eric Woudstra reported that a PCS attached using 2500base-X does not see link when phylink is using in-band mode, but autoneg is disabled, despite there being a valid 2500base-X signal being received. We have these settings: act_link_an_mode = MLO_AN_INBAND pcs_neg_mode = PHYLINK_PCS_NEG_INBAND_DISABLED Eric diagnosed it to phylink_decode_c37_word() setting state->link false because the full-duplex bit isn't set in the non-existent link partner advertisement word (which doesn't exist because in-band autoneg is disabled!) The test in phylink_mii_c22_pcs_decode_state() is supposed to catch this state, but since we converted PCS to use neg_mode, testing the Autoneg in the local advertisement is no longer sufficient - we need to be looking at the neg_mode, which currently isn't provided. We need to provide this via the .pcs_get_state() method, and this will require modifying all PCS implementations to add the extra argument to this method. Patch 1 uses the PCS neg_mode in phylink_mac_pcs_get_state() to correct the now obsolute usage of the Autoneg bit in the advertisement. Patch 2 passes neg_mode into the .pcs_get_state() method, and updates all users. Patch 3 adds neg_mode as an argument to the various clause 22 state decoder functions in phylink, modifying drivers to pass the neg_mode through. Patch 4 makes use of phylink_mii_c22_pcs_decode_state() rather than using the Autoneg bit in the advertising field. Patch 5 may be required for Eric's case - it ensures that we report the correct state for interface types that we support only one set of modes for when autoneg is disabled. ==================== Link: https://patch.msgid.link/Z4TbR93B-X8A8iHe@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: provide fixed state for 1000base-X and 2500base-XRussell King (Oracle)
When decoding clause 22 state, if in-band is disabled and using either 1000base-X or 2500base-X, rather than reporting link-down, we know the speed, and we only support full duplex. Pause modes taken from XPCS. This fixes a problem reported by Eric Woudstra. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGei-000EtL-Fn@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: use neg_mode in phylink_mii_c22_pcs_decode_state()Russell King (Oracle)
Rather than using the state of the Autoneg bit, which is unreliable with the new PCS neg mode support, use the passed neg_mode to decide whether to decode the link partner advertisement data. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGed-000EtF-CN@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: pass neg_mode into c22 state decoderRussell King (Oracle)
Pass the current neg_mode into phylink_mii_c22_pcs_get_state() and phylink_mii_c22_pcs_decode_state(). Update all users of phylink PCS that use these functions. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeY-000Et9-8g@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: pass neg_mode into .pcs_get_state() methodRussell King (Oracle)
Pass the current neg_mode into the .pcs_get_state() method. Update all users of phylink PCS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeT-000Et3-4L@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: phylink: use pcs_neg_mode in phylink_mac_pcs_get_state()Russell King (Oracle)
As in-band AN no longer just depends on MLO_AN_INBAND + Autoneg bit, we need to take account of the pcs_neg_mode when deciding how to initialise the speed, duplex and pause state members before calling into the .pcs_neg_mode() method. Add this. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/E1tXGeO-000Esx-0r@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: pcs: xpcs: actively unset DW_VR_MII_DIG_CTRL1_2G5_EN for 1G SGMIIVladimir Oltean
xpcs_config_2500basex() sets DW_VR_MII_DIG_CTRL1_2G5_EN, but xpcs_config_aneg_c37_sgmii() never unsets it. So, on a protocol change from 2500base-x to sgmii, the DW_VR_MII_DIG_CTRL1_2G5_EN bit will remain set. Fixes: f27abde3042a ("net: pcs: add 2500BASEX support for Intel mGbE controller") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250114164721.2879380-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: pcs: xpcs: fix DW_VR_MII_DIG_CTRL1_2G5_EN bit being set for 1G SGMII ↵Vladimir Oltean
w/o inband On a port with SGMII fixed-link at SPEED_1000, DW_VR_MII_DIG_CTRL1 gets set to 0x2404. This is incorrect, because bit 2 (DW_VR_MII_DIG_CTRL1_2G5_EN) is set. It comes from the previous write to DW_VR_MII_AN_CTRL, because the "val" variable is reused and is dirty. Actually, its value is 0x4, aka FIELD_PREP(DW_VR_MII_PCS_MODE_MASK, DW_VR_MII_PCS_MODE_C37_SGMII). Resolve the issue by clearing "val" to 0 when writing to a new register. After the fix, the register value is 0x2400. Prior to the blamed commit, when the read-modify-write was open-coded, the code saved the content of the DW_VR_MII_DIG_CTRL1 register in the "ret" variable. Fixes: ce8d6081fcf4 ("net: pcs: xpcs: add _modify() accessors") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250114164721.2879380-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15Merge branch 'mptcp-selftests-more-debug-in-case-of-errors'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: selftests: more debug in case of errors Here are just a bunch of small improvements for the MPTCP selftests: Patch 1: Unify errors messages in simult_flows: print MIB and 'ss -Me'. Patch 2: Unify errors messages in sockopt: print MIB. Patch 3: Move common code to print debug info to mptcp_lib.sh. Patch 4: Use 'ss' with '-m' in case of errors. Patch 5: Remove an unused variable. Patch 6: Print only the size instead of size + filename again. ==================== Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-0-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests: mptcp: connect: better display the files sizeMatthieu Baerts (NGI0)
'du' will print the name of the file, which was already displayed before, e.g. Created /tmp/tmp.UOyy0ghfmQ (size 4703740/tmp/tmp.UOyy0ghfmQ) containing data sent by client Created /tmp/tmp.xq3zvFinGo (size 1391724/tmp/tmp.xq3zvFinGo) containing data sent by server 'stat' can be used instead, to display this instead: Created /tmp/tmp.UOyy0ghfmQ (size 4703740 B) containing data sent by client Created /tmp/tmp.xq3zvFinGo (size 1391724 B) containing data sent by server So easier to spot the file sizes. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-6-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests: mptcp: connect: remove unused variableMatthieu Baerts (NGI0)
'cin_disconnect' is used in run_tests_disconnect(), but not 'cout_disconnect', so it is safe to drop it. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-5-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests: mptcp: add -m with ss in case of errorsMatthieu Baerts (NGI0)
Recently, we had an issue where getting info about the memory would have helped better understanding what went wrong. Let add it just in case for later. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-4-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests: mptcp: move stats info in case of errors to lib.shMatthieu Baerts (NGI0)
A few MPTCP selftests are using the same code to print stats in case of error. This code can then be moved to mptcp_lib.sh. No behaviour changes intended, except to print the error in red and to stderr, like most error messages. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-3-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests: mptcp: sockopt: save nstat infosGeliang Tang
Similar to the way nstat information is stored in mptcp_connect.sh and mptcp_join.sh scripts, this patch adds a similar way for mptcp_sockopt.sh and displays the nstat information when errors occur. Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-2-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15selftests: mptcp: simult_flows: unify errors msgsMatthieu Baerts (NGI0)
In order to unify what is printed in case of error, similar to what is done in mptcp_connect.sh and mptcp_join.sh, it is interesting to do the following modifications in simult_flows.sh: - Print the rc errors at the end of the line. - Print the MIB counters. - Use the same ss options: add -M (MPTCP sockets) and -e (detailed socket information). While at it, also print of the 'max' time only in case of success, because 'mptcp_connect.c' will already print this info in case of error, e.g.: transfer slower than expected! runtime 11948 ms, expected 11921 ms Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-st-more-debug-err-v1-1-2ffb16a6cf35@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15mptcp: fix for setting remote ipv4mapped addressGeliang Tang
Commit 1c670b39cec7 ("mptcp: change local addr type of subflow_destroy") introduced a bug in mptcp_pm_nl_subflow_destroy_doit(). ipv6_addr_set_v4mapped() should be called to set the remote ipv4 address 'addr_r.addr.s_addr' to the remote ipv6 address 'addr_r.addr6', not 'addr_l.addr.addr6', which is the local ipv6 address. Fixes: 1c670b39cec7 ("mptcp: change local addr type of subflow_destroy") Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250114-net-next-mptcp-fix-remote-addr-v1-1-debcd84ea86f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15Merge branch 'net-bcm-asp2-fix-fallout-from-phylib-eee-changes'Jakub Kicinski
Russell King says: ==================== net: bcm: asp2: fix fallout from phylib EEE changes This series addresses the fallout from the phylib changes in the Broadcom ASP2 driver. The first patch uses phylib's copy of the LPI timer setting, which means the driver no longer has to track this. It will be set in hardware each time the adjust_link function is called when the link is up, and will be read at initialisation time to set the current value. The second patch removes the driver's storage of tx_lpi_enabled, which has become redundant since phylib managed EEE was merged. The driver does nothing with this flag other than storing it. The last patch converts the driver to use phylib's enable_tx_lpi flag rather than trying to maintain its own copy. ==================== Link: https://patch.msgid.link/Z4aV3RmSZJ1WS3oR@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: bcm: asp2: convert to phylib managed EEERussell King (Oracle)
Convert the Broadcom ASP2 driver to use phylib managed EEE support. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/E1tXk81-000r4x-TS@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: bcm: asp2: remove tx_lpi_enabledRussell King (Oracle)
Phylib maintains a copy of tx_lpi_enabled, which will be used to populate the member when phy_ethtool_get_eee(). Therefore, writing to this member before phy_ethtool_get_eee() will have no effect. Remove it. Also remove setting our copy of info->eee.tx_lpi_enabled which becomes write-only. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/E1tXk7w-000r4r-Pq@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15net: bcm: asp2: fix LPI timer handlingRussell King (Oracle)
Fix the LPI timer handling in Broadcom ASP2 driver after the phylib managed EEE patches were merged. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/E1tXk7r-000r4l-Li@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-15i2c: add kdoc for the new debugfs entry of clientsWolfram Sang
When adding the new debugfs entry, its kdoc equivalent was forgotten. Add it now. Fixes: d06905d68610 ("i2c: add core-managed per-client directory in debugfs") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20250115163146.6c48f066@canb.auug.org.au Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-01-15power: supply: max17042: add platform driver variantDzmitry Sankouski
Maxim PMICs may include fuel gauge with additional features, which is out of single Linux power supply driver scope. For example, in max77705 PMIC fuelgauge has additional registers, like IIN_REG, VSYS_REG, ISYS_REG. Those needed to measure PMIC input current, system voltage and current respectively. Those measurements cannot be bound to any of fuelgauge properties. The solution here add and option to use max17042 driver as a MFD sub device, thus allowing any additional functionality be implemented as another sub device. This will help to reduce code duplication in MFD fuel gauge drivers. Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250107-b4-max17042-v6-2-3d0104ad5bc7@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15power: supply: max17042: make interrupt sharedDzmitry Sankouski
Fuelgauge blocks often are incorporated in bigger chip, which may use only 1 line for interrupts. Make interrupt shared. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250107-b4-max17042-v6-1-3d0104ad5bc7@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-01-15PCI: apple: Convert to {en,dis}able_device() callbacksMarc Zyngier
Now that the core host-bridge infrastructure is able to give us a callback on each device being added or removed, convert the bus-notifier hack to it. Link: https://lore.kernel.org/r/20241204150145.800408-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
2025-01-15PCI: host-generic: Allow {en,dis}able_device() to be provided via pci_ecam_opsMarc Zyngier
In order to let host controller drivers using the host-generic infrastructure use the {en,dis}able_device() callbacks that can be used to configure sideband RID mapping hardware, provide these two callbacks as part of the pci_ecam_ops structure. Link: https://lore.kernel.org/r/20241204150145.800408-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
generated by cgit (git 2.34.1) at 2025-09-19 05:34:20 +0000