* [PATCH v5 0/3] ksz87xx: add support for low-loss cable equalizer errata
From: Fidelio Lawson @ 2026-05-05 11:42 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Marek Vasut, Maxime Chevallier, Simon Horman, Heiner Kallweit,
Russell King, Tristram Ha
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
Hello,
This patch implements the “Module 3: Equalizer fix for short cables” erratum
described in Microchip document DS80000687C for KSZ87xx switches.
According to the erratum, the embedded PHY receiver in KSZ87xx switches is
tuned by default for long, high-loss Ethernet cables. When operating with
short or low-loss cables (for example CAT5e or CAT6), the PHY equalizer may
over-amplify the incoming signal, leading to internal distortion and link
establishment failures.
Microchip documents two independent mechanisms to mitigate this issue:
adjusting the receiver low‑pass filter bandwidth and reducing the DSP
equalizer initial value. These registers are located in the switch’s
internal LinkMD table and cannot be accessed directly through a
stand‑alone PHY driver.
To keep the PHY‑facing API clean, this series models the erratum handling
as vendor‑specific Clause 22 PHY registers, virtualized by the KSZ8 DSA
driver. Accesses are intercepted by ksz8_r_phy() / ksz8_w_phy() and
translated into the appropriate indirect LinkMD register writes. The
erratum affects the shared PHY analog front‑end and therefore applies
globally to the switch.
Based on review feedback, the user‑visible interface is kept deliberately
simple and predictable:
- A boolean “short‑cable” PHY tunable applies a documented and
conservative preset (LPF bandwidth 62MHz, DSP EQ initial value 0).
This is the recommended KISS interface for the common short‑cable
scenario.
- Two additional integer PHY tunables allow advanced or experimental
tuning of the LPF bandwidth and the DSP EQ initial value. These
controls are orthogonal, have no ordering requirements, and simply
override the corresponding setting when written.
The tunables act as simple setters with no implicit state machine or
invalid combinations, avoiding surprises for userspace and not relying
on extended error reporting or netlink ethtool support.
This series contains:
1. Support for the KSZ87xx low‑loss cable erratum in the KSZ8 DSA driver,
including the short‑cable preset and orthogonal tuning controls.
2. Addition of vendor‑specific PHY tunable identifiers for the
short‑cable preset, LPF bandwidth, and DSP EQ initial value.
3. Exposure of these tunables through the Micrel PHY driver via
get_tunable / set_tunable callbacks.
This version follows the design agreed upon during v3 review and
reworks the interface accordingly.
This series is based on Linux v7.0-rc1.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
Changes in v5:
- Added Fixes tag
- Added validation to ensure that only the documented bitfields are accepted before writing the registers
- Link to v4: https://patch.msgid.link/20260417-ksz87xx_errata_low_loss_connections-v4-0-6c7044ec4363@exotec.com
Changes in v4:
- Reworked the user‑visible API to a boolean short‑cable preset plus
orthogonal advanced tunables, following the KISS principle.
- Dropped the previous mode‑selector semantics in favor of simple
setters with no ordering requirements
- Added persistent tracking of LPF bandwidth and EQ initial value.
- Clarified defaults and preset values to match Microchip documentation.
- Link to v3: https://patch.msgid.link/20260414-ksz87xx_errata_low_loss_connections-v3-0-0e3838ca98c9@exotec.com
Changes in v3:
- Exposed all LPF bandwidth values supported by the hardware.
- Added phy tunable.
- Link to v2: https://patch.msgid.link/20260408-ksz87xx_errata_low_loss_connections-v2-1-9cfe38691713@exotec.com
Changes in v2:
- Dropped the device tree approach based on review feedback
- Modeled the errata control as a vendor-specific Clause 22 PHY register
- Added KSZ87xx-specific guards and replaced magic values with named macros
- Rebased on Linux v7.0-rc1
- Link to v1: https://patch.msgid.link/20260326-ksz87xx_errata_low_loss_connections-v1-0-79a698f43626@exotec.com
---
Fidelio Lawson (3):
net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
net: ethtool: add KSZ87xx low-loss cable PHY tunables
net: phy: micrel: expose KSZ87xx low-loss cable tunables
drivers/net/dsa/microchip/ksz8.c | 73 ++++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz8.h | 1 +
drivers/net/dsa/microchip/ksz8_reg.h | 24 ++++++++++-
drivers/net/dsa/microchip/ksz_common.h | 4 ++
drivers/net/phy/micrel.c | 54 +++++++++++++++++++++++++
include/uapi/linux/ethtool.h | 3 ++
net/ethtool/common.c | 3 ++
net/ethtool/ioctl.c | 3 ++
8 files changed, 164 insertions(+), 1 deletion(-)
---
base-commit: 2d1373e4246da3b58e1df058374ed6b101804e07
change-id: 20260323-ksz87xx_errata_low_loss_connections-b65e76e2b403
Best regards,
--
Fidelio Lawson <fidelio.lawson@exotec.com>
^ permalink raw reply
* [PATCH v5 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio Lawson @ 2026-05-05 11:42 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Marek Vasut, Maxime Chevallier, Simon Horman, Heiner Kallweit,
Russell King, Tristram Ha
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <20260505-ksz87xx_errata_low_loss_connections-v5-0-da4002b21c42@exotec.com>
Implement the "Module 3: Equalizer fix for short cables" erratum from
Microchip document DS80000687C for KSZ87xx switches.
The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
where the PHY receiver equalizer may amplify high-amplitude signals
excessively, resulting in internal distortion and link establishment
failures.
KSZ87xx devices require a workaround for the Module 3 low-loss cable
condition, controlled through the switch TABLE_LINK_MD_V indirect
registers.
This change models the erratum handling as vendor-specific Clause 22 PHY
registers, virtualized by the KSZ8 DSA driver and accessed via
ksz8_r_phy() / ksz8_w_phy(). The following controls are provided:
- A boolean “short-cable” preset, which applies a documented and
conservative configuration (LPF 62 MHz bandwidth and DSP EQ initial
value 0), and is the recommended interface for typical use cases.
- Separate LPF bandwidth and DSP EQ initial value controls intended for
advanced or experimental tuning. These are orthogonal and independent,
and override the corresponding settings without requiring any specific
ordering.
The preset and tunables act as simple setters with no implicit state
machine or invalid combinations, keeping the API predictable and aligned
with the KISS principle.
The erratum affects the shared PHY analog front-end and therefore applies
globally to the switch.
Fixes: e66f840c08a2 ("net: dsa: ksz: Add Microchip KSZ8795 DSA driver")
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
drivers/net/dsa/microchip/ksz8.c | 73 ++++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz8.h | 1 +
drivers/net/dsa/microchip/ksz8_reg.h | 24 ++++++++++-
drivers/net/dsa/microchip/ksz_common.h | 4 ++
4 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
index c354abdafc1b..62fc59c3da7e 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1058,6 +1058,22 @@ int ksz8_r_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 *val)
if (ret)
return ret;
+ break;
+ case PHY_REG_KSZ87XX_SHORT_CABLE:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ data = !!(dev->lpf_bw == KSZ87XX_PHY_LPF_62MHZ &&
+ dev->eq_init == KSZ87XX_DSP_EQ_INIT_LOW_LOSS);
+ break;
+ case PHY_REG_KSZ87XX_LPF_BW:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ data = dev->lpf_bw;
+ break;
+ case PHY_REG_KSZ87XX_EQ_INIT:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ data = dev->eq_init;
break;
default:
processed = false;
@@ -1271,6 +1287,35 @@ int ksz8_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val)
if (ret)
return ret;
break;
+ case PHY_REG_KSZ87XX_SHORT_CABLE:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ ret = ksz87xx_apply_low_loss_preset(dev, !!val);
+ if (ret)
+ return ret;
+ break;
+ case PHY_REG_KSZ87XX_LPF_BW:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ /* Only accept LPF bandwidth bits [7:6] */
+ if (val & ~KSZ87XX_LPF_VALID_MASK)
+ return -EINVAL;
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF, (u8)val);
+ if (ret)
+ return ret;
+ dev->lpf_bw = val;
+ break;
+ case PHY_REG_KSZ87XX_EQ_INIT:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ /* Only accept DSP EQ initial value bits [5:0] */
+ if (val & ~KSZ87XX_DSP_EQ_VALID_MASK)
+ return -EINVAL;
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_DSP_EQ, (u8)val);
+ if (ret)
+ return ret;
+ dev->eq_init = val;
+ break;
default:
break;
}
@@ -2096,11 +2141,39 @@ int ksz8463_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val)
return 0;
}
+int ksz87xx_apply_low_loss_preset(struct ksz_device *dev, bool enable)
+{
+ /* Apply the Microchip erratum short-cable preset (LPF 62 MHz, EQ init 0) */
+ /* providing a conservative configuration for short or low-loss cables. */
+ u8 lpf_bw, eq_init;
+ int ret;
+
+ lpf_bw = KSZ87XX_PHY_LPF_62MHZ;
+ eq_init = KSZ87XX_DSP_EQ_INIT_LOW_LOSS;
+
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ if (!enable)
+ return 0;
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF, lpf_bw);
+ if (ret)
+ return ret;
+ dev->lpf_bw = lpf_bw;
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_DSP_EQ, eq_init);
+ if (ret)
+ return ret;
+ dev->eq_init = eq_init;
+
+ return ret;
+}
+
int ksz8_switch_init(struct ksz_device *dev)
{
dev->cpu_port = fls(dev->info->cpu_ports) - 1;
dev->phy_port_cnt = dev->info->port_cnt - 1;
dev->port_mask = (BIT(dev->phy_port_cnt) - 1) | dev->info->cpu_ports;
+ dev->lpf_bw = KSZ87XX_PHY_LPF_90MHZ;
+ dev->eq_init = KSZ87XX_DSP_EQ_INIT_FACTORY;
return 0;
}
diff --git a/drivers/net/dsa/microchip/ksz8.h b/drivers/net/dsa/microchip/ksz8.h
index 0f2cd1474b44..5cf7bd90af0f 100644
--- a/drivers/net/dsa/microchip/ksz8.h
+++ b/drivers/net/dsa/microchip/ksz8.h
@@ -66,5 +66,6 @@ int ksz8_all_queues_split(struct ksz_device *dev, int queues);
u32 ksz8463_get_port_addr(int port, int offset);
int ksz8463_r_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 *val);
int ksz8463_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val);
+int ksz87xx_apply_low_loss_preset(struct ksz_device *dev, bool enable);
#endif
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h
index 332408567b47..cd41214f874e 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -202,6 +202,13 @@
#define REG_PORT_3_STATUS_0 0x38
#define REG_PORT_4_STATUS_0 0x48
+/* KSZ87xx LinkMD registers (TABLE_LINK_MD_V) */
+#define KSZ87XX_REG_DSP_EQ 0x08 /* DSP EQ initial value */
+#define KSZ87XX_REG_PHY_LPF 0x4C /* RX LPF bandwidth */
+
+#define KSZ87XX_DSP_EQ_VALID_MASK GENMASK(5, 0)
+#define KSZ87XX_LPF_VALID_MASK GENMASK(7, 6)
+
/* For KSZ8765. */
#define PORT_REMOTE_ASYM_PAUSE BIT(5)
#define PORT_REMOTE_SYM_PAUSE BIT(4)
@@ -342,7 +349,7 @@
#define TABLE_EEE (TABLE_EEE_V << TABLE_EXT_SELECT_S)
#define TABLE_ACL (TABLE_ACL_V << TABLE_EXT_SELECT_S)
#define TABLE_PME (TABLE_PME_V << TABLE_EXT_SELECT_S)
-#define TABLE_LINK_MD (TABLE_LINK_MD << TABLE_EXT_SELECT_S)
+#define TABLE_LINK_MD (TABLE_LINK_MD_V << TABLE_EXT_SELECT_S)
#define TABLE_READ BIT(4)
#define TABLE_SELECT_S 2
#define TABLE_STATIC_MAC_V 0
@@ -729,6 +736,21 @@
#define PHY_POWER_SAVING_ENABLE BIT(2)
#define PHY_REMOTE_LOOPBACK BIT(1)
+/* Vendor-specific Clause 22 PHY registers (virtualized) */
+#define PHY_REG_KSZ87XX_SHORT_CABLE 0x1A
+#define PHY_REG_KSZ87XX_LPF_BW 0x1B
+#define PHY_REG_KSZ87XX_EQ_INIT 0x1C
+
+/* LPF bandwidth bits [7:6]: 00 = 90MHz (default), 01 = 62MHz, 10 = 55MHz, 11 = 44MHz */
+#define KSZ87XX_PHY_LPF_90MHZ 0x00
+#define KSZ87XX_PHY_LPF_62MHZ 0x40
+#define KSZ87XX_PHY_LPF_55MHZ 0x80
+#define KSZ87XX_PHY_LPF_44MHZ 0xC0
+
+/* Low-loss workaround DSP EQ INIT VALUE */
+#define KSZ87XX_DSP_EQ_INIT_LOW_LOSS 0x00
+#define KSZ87XX_DSP_EQ_INIT_FACTORY 0x0F
+
/* KSZ8463 specific registers. */
#define P1MBCR 0x4C
#define P1MBSR 0x4E
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 929aff4c55de..482e79cf6ae6 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -219,6 +219,10 @@ struct ksz_device {
* the switch’s internal PHYs, bypassing the main SPI interface.
*/
struct mii_bus *parent_mdio_bus;
+
+ /* KSZ87xx low-loss tuning state */
+ u8 lpf_bw; /* KSZ87XX_PHY_LPF_* */
+ u8 eq_init; /* DSP EQ initial value */
};
/* List of supported models */
--
2.54.0
^ permalink raw reply related
* [PATCH v5 2/3] net: ethtool: add KSZ87xx low-loss cable PHY tunables
From: Fidelio Lawson @ 2026-05-05 11:42 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Marek Vasut, Maxime Chevallier, Simon Horman, Heiner Kallweit,
Russell King, Tristram Ha
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <20260505-ksz87xx_errata_low_loss_connections-v5-0-da4002b21c42@exotec.com>
Introduce vendor-specific PHY tunable identifiers to control the
KSZ87xx low-loss cable erratum handling through the ethtool PHY
tunable interface.
The following tunables are added:
- a boolean "short-cable" tunable, applying a documented and
conservative preset intended for short or low-loss Ethernet cables;
- an integer LPF bandwidth tunable, allowing advanced adjustment of the
receiver low-pass filter bandwidth;
- an integer DSP EQ initial value tunable, allowing advanced tuning of
the PHY equalizer initialization.
The actual behavior is implemented by the corresponding PHY and switch
drivers.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
include/uapi/linux/ethtool.h | 3 +++
net/ethtool/common.c | 3 +++
net/ethtool/ioctl.c | 3 +++
3 files changed, 9 insertions(+)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index b74b80508553..081d8f2191b6 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -291,6 +291,9 @@ enum phy_tunable_id {
ETHTOOL_PHY_DOWNSHIFT,
ETHTOOL_PHY_FAST_LINK_DOWN,
ETHTOOL_PHY_EDPD,
+ ETHTOOL_PHY_SHORT_CABLE_PRESET,
+ ETHTOOL_PHY_LPF_BW,
+ ETHTOOL_PHY_DSP_EQ_INIT_VALUE,
/*
* Add your fresh new phy tunable attribute above and remember to update
* phy_tunable_strings[] in net/ethtool/common.c
diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index e252cf20c22f..9c2fe5b626d6 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c
@@ -101,6 +101,9 @@ phy_tunable_strings[__ETHTOOL_PHY_TUNABLE_COUNT][ETH_GSTRING_LEN] = {
[ETHTOOL_PHY_DOWNSHIFT] = "phy-downshift",
[ETHTOOL_PHY_FAST_LINK_DOWN] = "phy-fast-link-down",
[ETHTOOL_PHY_EDPD] = "phy-energy-detect-power-down",
+ [ETHTOOL_PHY_SHORT_CABLE_PRESET] = "phy-short-cable-preset",
+ [ETHTOOL_PHY_LPF_BW] = "phy-lpf-bandwidth",
+ [ETHTOOL_PHY_DSP_EQ_INIT_VALUE] = "phy-dsp-eq-init-value",
};
#define __LINK_MODE_NAME(speed, type, duplex) \
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index ff4b4780d6af..5b66e4a96f67 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -3109,6 +3109,9 @@ static int ethtool_phy_tunable_valid(const struct ethtool_tunable *tuna)
switch (tuna->id) {
case ETHTOOL_PHY_DOWNSHIFT:
case ETHTOOL_PHY_FAST_LINK_DOWN:
+ case ETHTOOL_PHY_SHORT_CABLE_PRESET:
+ case ETHTOOL_PHY_LPF_BW:
+ case ETHTOOL_PHY_DSP_EQ_INIT_VALUE:
if (tuna->len != sizeof(u8) ||
tuna->type_id != ETHTOOL_TUNABLE_U8)
return -EINVAL;
--
2.54.0
^ permalink raw reply related
* [PATCH v5 3/3] net: phy: micrel: expose KSZ87xx low-loss cable tunables
From: Fidelio Lawson @ 2026-05-05 11:42 UTC (permalink / raw)
To: Woojung Huh, UNGLinuxDriver, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Marek Vasut, Maxime Chevallier, Simon Horman, Heiner Kallweit,
Russell King, Tristram Ha
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <20260505-ksz87xx_errata_low_loss_connections-v5-0-da4002b21c42@exotec.com>
Add support for the KSZ87xx low-loss cable PHY tunables in the Micrel
PHY driver by implementing get_tunable and set_tunable callbacks.
These callbacks expose vendor-specific PHY tunables used to control the
KSZ87xx embedded PHY receiver behavior when operating with short or
low-loss Ethernet cables. The tunables provide:
- a boolean short-cable preset applying known good settings;
- an integer LPF bandwidth control;
- an integer DSP EQ initial value control.
The Micrel PHY driver forwards these tunables via standard phy_read() /
phy_write() operations, which are virtualized by the KSZ8 DSA driver and
translated into the appropriate indirect switch register accesses.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
drivers/net/phy/micrel.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index c6b011a9d636..1852e9bd0e01 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -287,6 +287,12 @@
/* PHY Control 2 / PHY Control (if no PHY Control 1) */
#define MII_KSZPHY_CTRL_2 0x1f
#define MII_KSZPHY_CTRL MII_KSZPHY_CTRL_2
+
+/* Vendor-specific Clause 22 register, virtualized by KSZ87xx embedded PHYs DSA driver */
+#define MII_KSZ87XX_SHORT_CABLE 0x1a
+#define MII_KSZ87XX_LPF_BW 0x1b
+#define MII_KSZ87XX_EQ_INIT 0x1c
+
/* bitmap of PHY register to set interrupt mode */
#define KSZ8081_CTRL2_HP_MDIX BIT(15)
#define KSZ8081_CTRL2_MDI_MDI_X_SELECT BIT(14)
@@ -940,6 +946,52 @@ static int ksz8795_match_phy_device(struct phy_device *phydev,
return ksz8051_ksz8795_match_phy_device(phydev, false);
}
+static int ksz87xx_get_tunable(struct phy_device *phydev,
+ struct ethtool_tunable *tuna, void *data)
+{
+ int ret;
+
+ switch (tuna->id) {
+ case ETHTOOL_PHY_SHORT_CABLE_PRESET:
+ ret = phy_read(phydev, MII_KSZ87XX_SHORT_CABLE);
+ if (ret < 0)
+ return ret;
+ *(u8 *)data = ret;
+ return 0;
+ case ETHTOOL_PHY_LPF_BW:
+ ret = phy_read(phydev, MII_KSZ87XX_LPF_BW);
+ if (ret < 0)
+ return ret;
+ *(u8 *)data = ret;
+ return 0;
+ case ETHTOOL_PHY_DSP_EQ_INIT_VALUE:
+ ret = phy_read(phydev, MII_KSZ87XX_EQ_INIT);
+ if (ret < 0)
+ return ret;
+ *(u8 *)data = ret;
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int ksz87xx_set_tunable(struct phy_device *phydev,
+ struct ethtool_tunable *tuna, const void *data)
+{
+ u8 val = *(const u8 *)data;
+
+ switch (tuna->id) {
+ case ETHTOOL_PHY_SHORT_CABLE_PRESET:
+ return phy_write(phydev, MII_KSZ87XX_SHORT_CABLE, val);
+ case ETHTOOL_PHY_LPF_BW:
+ return phy_write(phydev, MII_KSZ87XX_LPF_BW, val);
+ case ETHTOOL_PHY_DSP_EQ_INIT_VALUE:
+ return phy_write(phydev, MII_KSZ87XX_EQ_INIT, val);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static int ksz9021_load_values_from_of(struct phy_device *phydev,
const struct device_node *of_node,
u16 reg,
@@ -6809,6 +6861,8 @@ static struct phy_driver ksphy_driver[] = {
/* PHY_BASIC_FEATURES */
.config_init = kszphy_config_init,
.match_phy_device = ksz8795_match_phy_device,
+ .get_tunable = ksz87xx_get_tunable,
+ .set_tunable = ksz87xx_set_tunable,
.suspend = genphy_suspend,
.resume = genphy_resume,
}, {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v2] declance: Remove IRQF_ONESHOT
From: Maciej W. Rozycki @ 2026-05-05 12:02 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: netdev, linux-mips, Jakub Kicinski, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni
In-Reply-To: <20260505072954.Ov2t-FGt@linutronix.de>
On Tue, 5 May 2026, Sebastian Andrzej Siewior wrote:
> > No reply, but I've gone through irq_setup_forced_threading() now and my
> > inference was indeed correct, and the handler does need to be installed
> > with IRQF_NO_THREAD. I'll send corrective patches shortly.
>
> Sorry. I missed that previous email.
> IRQF_NO_THREAD will not force-thread the interrupt handler so it will
> run with interrupts disabled.
That's one clear option I've identified and given that the handler
amounts to a printk() call it may well be the path of least resistance
solution.
> With force-threading enabled, the interrupt handler is masked in the
> IRQ-chip until after the threaded-handler run. See the cond_unmask_irq()
> in handle_level_irq() or the mask_irq() & cond_unmask_eoi_irq() in
> handle_fasteoi_ack_irq(). That means the hw-IRQ is done, the thread is
> running with interrupts enabled but the hw-IRQ will not trigger again.
> The cited commit 5a4a4ad851dd8 ("MIPS: Mark cascade and low level
> interrupts IRQF_NO_THREAD") is different as it acts on cascading
> interrupts which is not what we have here.
Not with the current handle_fasteoi_irq() handler.
And actually not with handle_fasteoi_ack_irq() either, which doesn't call
mask_irq() unless IRQF_ONESHOT has been requested (but ->irq_ack() could
be repurposed to do masking), however handle_fasteoi_mask_irq() seems a
matching candidate. To use that handler the platform would have to select
IRQ_DOMAIN_HIERARCHY and IRQ_FASTEOI_HIERARCHY_HANDLERS, although none of
the stuff beyond just handle_fasteoi_mask_irq() appears relevant, so it
seems like a waste of memory. Note that the handlers are much more recent
than the driver and back in the time IRQF_ONESHOT seemed a reasonable
approach.
The handle_level_irq() handler is irrelevant, because we do need to issue
the EOI for deassertion.
> If you request a threaded interrupt you must either provide two handler
> and the primary must mask the interrupt so it does not fire again or you
> pass a flag such as IRQF_ONESHOT and which point the IRQ subsystem will
> mask the IRQ within the irqchip so it does not fire again.
Well, yes, but you've just removed the flag from this driver, so either
the flag has to reinstated or the driver adjusted differently for the
threaded case to be handled correctly.
Maciej
^ permalink raw reply
* Re: [net-next PATCH v2 1/8] net: dsa: realtek: rtl8365mb: use ERR_PTR
From: Linus Walleij @ 2026-05-05 12:21 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-1-d064e220b391@gmail.com>
On Sun, May 3, 2026 at 8:18 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> Convert numeric error codes into human-readable strings by
> using %pe together with ERR_PTR() in dev_err() messages.
>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Andrew Lunn @ 2026-05-05 12:22 UTC (permalink / raw)
To: Maciek Machnikowski
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, vadim.fedorenko, horms
In-Reply-To: <b2ceffa3-a1d3-4124-b640-68fc11996f51@machnikowski.net>
On Tue, May 05, 2026 at 09:36:30AM +0200, Maciek Machnikowski wrote:
>
>
> On 04/05/2026 19:07, Jakub Kicinski wrote:
> > On Sun, 3 May 2026 09:47:47 +0200 Maciek Machnikowski wrote:
> >> Add PTP synchronization test using ptp4l and netdevsim.
> >>
> >> The test creates two netdevsim adapters, links them together
> >> and runs the ptp4l leader and ptp4l follower on two ends
> >> of the netdevsim link and waits for the follower to report the
> >> synchronized state (s2) in its output log.
> >>
> >> This implementation runs the test runs over IPv4 link.
> >
> > Doesn't seem to pass on netdevsim for us:
> >
> > # 41.13 [+40.95] # ptp4l follower did not reach locked state (s2) within 40s
> > # 41.13 [+0.00] # Follower log (last 10 lines): ptp4l[2179.605]: ioctl SIOCETHTOOL failed: Operation not supported | ptp4l[2179.607]: interface 'eth0' does not support requested timestamping mode | failed to create a clock
> > # 41.15 [+0.02] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 173, in ptp_sync_test:
> > # 41.15 [+0.01] # Check| _run_ptp4l_wait_sync(nsimsv.ifname, nsimcl.ifname, nssv.name, nscl.name)
> > # 41.16 [+0.01] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 99, in _run_ptp4l_wait_sync:
> > # 41.17 [+0.01] # Check| ksft_true(False, "PTP sync timeout")
> > # 41.17 [+0.00] # Check failed False does not eval to True PTP sync timeout
> > # 41.32 [+0.16] not ok 1 ptp.ptp_sync_test
> > # 41.33 [+0.00] # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
> >
> > Anything we need to do?
>
> Can you share the config file you used? Seems the PTP clock was not
> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
Shouldn't the configuration file be part of the test?
Andrew
^ permalink raw reply
* Re: [net-next PATCH v2 2/8] net: dsa: realtek: rtl8365mb: use dsa helpers for port iteration
From: Linus Walleij @ 2026-05-05 12:23 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel,
Abdulkader Alrezej
In-Reply-To: <20260503-realtek_forward-v2-2-d064e220b391@gmail.com>
On Sun, May 3, 2026 at 8:18 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> Use dsa_switch_for_each_*() whenever possible.
>
> For port setup(), a new blocking setup phase was added for all ports,
> including unused ones, before the user and CPU port setup.
>
> CPU isolation now includes all user ports as traffic was being blocked in
> some scenarios (suggested by Abdulkader Alrezej).
>
> Suggested-by: Abdulkader Alrezej <abdulkader.alrezej@gmail.com>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next PATCH v2 5/8] net: dsa: realtek: rtl8365mb: add VLAN support
From: Linus Walleij @ 2026-05-05 12:25 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel,
Yury Norov, Abdulkader Alrezej
In-Reply-To: <20260503-realtek_forward-v2-5-d064e220b391@gmail.com>
On Sun, May 3, 2026 at 8:19 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
> structures for VLANs:
>
> - VLAN4K: A full table with 4096 entries defining port membership and
> tagging.
> - VLANMC: A smaller table with 32 entries used primarily for PVID
> assignment.
>
> In this hardware, a port's PVID must point to an index in the VLANMC
> table rather than a VID directly. Since the VLANMC table is limited to
> 32 entries, the driver implements a dynamic allocation scheme to
> maximize resource usage:
>
> - VLAN4K is treated by the driver as the source of truth for membership.
> - A VLANMC entry is only allocated when a port is configured to use a
> specific VID as its PVID.
> - VLANMC entries are deleted when no longer needed as a PVID by any port.
>
> Although VLANMC has a members field, the switch only checks membership
> in the VLAN4K table. However, when a corresponding VLAN entry also exists
> in VLANMC, this driver keeps both membership configurations in sync.
>
> VLANMC index 0, although a valid entry, is reserved in this driver as a
> neutral PVID value for ports not using a specific PVID.
>
> In the subsequent RTL8367D switch family, VLANMC table was
> removed and PVID assignment was delegated to a dedicated set of
> registers.
>
> All ports start isolated, forwarding exclusively to CPU ports, and
> with VLAN transparent, ignoring VLAN membership. Once a member in a
> bridge, the port isolation is expanded to include the bridge members.
> When that bridge enables VLAN filtering, the VLAN transparent feature is
> disabled, letting the switch filter based on VLAN setup.
>
> The use of FIELD_PREP for reconstructing LO/HI values was suggested by
> Yury Norov.
>
> Fix for vlan_setup and vlan_filtering was suggested by Abdulkader
> Alrezej.
>
> Suggested-by: Yury Norov <ynorov@nvidia.com>
> Suggested-by: Abdulkader Alrezej <abdulkader.alrezej@gmail.com>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Allright go ahead like this. Mental not to move the RTL8366RB
VLAN handling down into the driver.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net v2] net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()
From: Andrew Lunn @ 2026-05-05 12:25 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Niklas Söderlund, Geert Uytterhoeven, Jakub Kicinski,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman, netdev,
linux-renesas-soc, linux-kernel, Shitalkumar Gandhi
In-Reply-To: <20260505085840.352206-1-shitalkumar.gandhi@cambiumnetworks.com>
On Tue, May 05, 2026 at 02:28:40PM +0530, Shitalkumar Gandhi wrote:
> of_get_child_by_name() takes a reference. The rtsn_reset() and
> rtsn_change_mode() failure paths jump to out_free_bus and leak
> mdio_node.
>
> Add out_put_node to drop it before falling through.
>
> Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN")
> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Changes in v2:
> - Restore blank line between `return 0;` and `out_put_node:` label (Geert)
> - Add Reviewed-by: Geert Uytterhoeven
Please always create a new thread for a new version of the
patch. Without that, the CI system just sees a comment to an existing
patch, and does not run. So this patch has not been through usual
testing, and will be ignored.
Andrew
^ permalink raw reply
* Re: [net-next PATCH v2 6/8] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
From: Linus Walleij @ 2026-05-05 12:25 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-6-d064e220b391@gmail.com>
On Sun, May 3, 2026 at 8:19 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Implement hardware offloading of bridge functionality. This is achieved
> by using the per-port isolation registers, which contain a forwarding
> port mask. The switch will refuse to forward packets ingressed on a
> given port to a port which is not in its forwarding mask.
>
> For each bridge that is offloaded, use the DSA-provided bridge number
> for the Extended Filtering ID (EFID). When using Independent VLAN
> Learning (IVL), the forwarding database is keyed with the tuple
> {VID, MAC, EFID}. There are 8 EFIDs available (0~7), but we reserve the
> default EFID 0 for standalone ports where learning is disabled. This
> fits nicely because DSA indexes the bridge number starting from 1.
>
> Because of the limited number of EFIDs, we have to set the
> max_num_bridges property of our switch to 7: we can't offload more than
> that or we will fail to offer IVL as at least two bridges would end up
> having to share an EFID.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Sweet, exactly like this! Good work.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next PATCH v2 7/8] net: dsa: realtek: rtl8365mb: add FDB support
From: Linus Walleij @ 2026-05-05 12:27 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-7-d064e220b391@gmail.com>
On Sun, May 3, 2026 at 8:19 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Implement support for FDB and MDB management for the RTL8365MB series
> switches.
>
> The hardware supports IVL by keying the forwarding database with the
> {VID, MAC, EFID} tuple. The Extended Filtering ID (EFID) is 3 bits
> wide, providing 8 unique filtering domains. This driver reserves EFID 0
> for standalone ports, effectively limiting the hardware offload to a
> maximum of 7 bridges.
>
> Introduce a mutex lock (l2_lock) to protect concurrent L2 table updates.
>
> Add support for forwarding database operations, including unicast and
> multicast entry handling as well as fast aging support.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Excellent, thanks!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [net-next PATCH v2 8/8] net: dsa: realtek: rtl8365mb: add bridge port flags
From: Linus Walleij @ 2026-05-05 12:27 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-8-d064e220b391@gmail.com>
On Sun, May 3, 2026 at 8:19 AM Luiz Angelo Daros de Luca
<luizluca@gmail.com> wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Implement support for bridge port flags to control learning and flooding
> behavior. This patch maps hardware functionalities to the following
> bridge flags:
>
> - BR_LEARNING
> - BR_FLOOD
> - BR_MCAST_FLOOD
> - BR_BCAST_FLOOD
>
> By default, all flooding types are enabled during port setup to ensure
> standard bridge behavior.
>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Excellent again, thanks.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v2] declance: Remove IRQF_ONESHOT
From: Sebastian Andrzej Siewior @ 2026-05-05 12:32 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: netdev, linux-mips, Jakub Kicinski, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni
In-Reply-To: <alpine.DEB.2.21.2605051233210.46195@angie.orcam.me.uk>
On 2026-05-05 13:02:16 [+0100], Maciej W. Rozycki wrote:
> > With force-threading enabled, the interrupt handler is masked in the
> > IRQ-chip until after the threaded-handler run. See the cond_unmask_irq()
> > in handle_level_irq() or the mask_irq() & cond_unmask_eoi_irq() in
> > handle_fasteoi_ack_irq(). That means the hw-IRQ is done, the thread is
> > running with interrupts enabled but the hw-IRQ will not trigger again.
> > The cited commit 5a4a4ad851dd8 ("MIPS: Mark cascade and low level
> > interrupts IRQF_NO_THREAD") is different as it acts on cascading
> > interrupts which is not what we have here.
>
> Not with the current handle_fasteoi_irq() handler.
Why? There is a mask_irq() in the ONESHOT case.
> And actually not with handle_fasteoi_ack_irq() either, which doesn't call
> mask_irq() unless IRQF_ONESHOT has been requested (but ->irq_ack() could
> be repurposed to do masking), however handle_fasteoi_mask_irq() seems a
> matching candidate. To use that handler the platform would have to select
> IRQ_DOMAIN_HIERARCHY and IRQ_FASTEOI_HIERARCHY_HANDLERS, although none of
> the stuff beyond just handle_fasteoi_mask_irq() appears relevant, so it
> seems like a waste of memory. Note that the handlers are much more recent
> than the driver and back in the time IRQF_ONESHOT seemed a reasonable
> approach.
If there is a chain and you have multiple controllers then the different
low-lever handler might be the way to go.
But IRQF_ONESHOT servers a different purpose. If you use request_irq()
then there is no threaded-handler and as such IRQF_ONESHOT does nothing
except avoiding force-threading the primary handler. But that is a
side-effet. If you want to avoid to force-threading the irq-handler then
IRQF_NO_THREAD would be the right flag.
> The handle_level_irq() handler is irrelevant, because we do need to issue
> the EOI for deassertion.
>
> > If you request a threaded interrupt you must either provide two handler
> > and the primary must mask the interrupt so it does not fire again or you
> > pass a flag such as IRQF_ONESHOT and which point the IRQ subsystem will
> > mask the IRQ within the irqchip so it does not fire again.
>
> Well, yes, but you've just removed the flag from this driver, so either
> the flag has to reinstated or the driver adjusted differently for the
> threaded case to be handled correctly.
But there is a plain request_irq() so the handler is invoked directly in
hardirq context with disabled interrupts. In forced-threaded context,
such as on PREEMPT_RT, the IRQF_ONESHOT is added.
> Maciej
Sebastian
^ permalink raw reply
* [PATCH net v2] net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()
From: Shitalkumar Gandhi @ 2026-05-05 12:32 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Andrew Lunn, Jakub Kicinski, David S . Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, netdev,
linux-renesas-soc, linux-kernel, Shitalkumar Gandhi
of_get_child_by_name() takes a reference. The rtsn_reset() and
rtsn_change_mode() failure paths jump to out_free_bus and leak
mdio_node.
Add out_put_node to drop it before falling through.
Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN")
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in v2:
- Restore blank line between `return 0;` and `out_put_node:` label (Geert)
- Add Reviewed-by: Geert Uytterhoeven
Resent as a new thread (no code changes) so netdev CI picks it up
(Andrew).
Link to v1: https://lore.kernel.org/netdev/20260504200356.3529873-1-shitalkumar.gandhi@cambiumnetworks.com/
Link to v2 (mis-threaded): https://lore.kernel.org/netdev/20260505085840.352206-1-shitalkumar.gandhi@cambiumnetworks.com/
drivers/net/ethernet/renesas/rtsn.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/renesas/rtsn.c b/drivers/net/ethernet/renesas/rtsn.c
index 03a2669f0518..ee8381b60b8d 100644
--- a/drivers/net/ethernet/renesas/rtsn.c
+++ b/drivers/net/ethernet/renesas/rtsn.c
@@ -797,11 +797,11 @@ static int rtsn_mdio_alloc(struct rtsn_private *priv)
/* Enter config mode before registering the MDIO bus */
ret = rtsn_reset(priv);
if (ret)
- goto out_free_bus;
+ goto out_put_node;
ret = rtsn_change_mode(priv, OCR_OPC_CONFIG);
if (ret)
- goto out_free_bus;
+ goto out_put_node;
rtsn_modify(priv, MPIC, MPIC_PSMCS_MASK | MPIC_PSMHT_MASK,
MPIC_PSMCS_DEFAULT | MPIC_PSMHT_DEFAULT);
@@ -824,6 +824,8 @@ static int rtsn_mdio_alloc(struct rtsn_private *priv)
return 0;
+out_put_node:
+ of_node_put(mdio_node);
out_free_bus:
mdiobus_free(mii);
return ret;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] net: phy: dp83867: add MDI-X management
From: Andrew Lunn @ 2026-05-05 12:34 UTC (permalink / raw)
To: Luca Ellero
Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260505122751.233764-1-l.ellero@asem.it>
On Tue, May 05, 2026 at 02:27:30PM +0200, Luca Ellero wrote:
> ethtool on this phy device always reports "MDI-X: Unknown" and doesn't
> support forcing it to on or off.
> This patch adds support for reading/forcing MDI-X mode from ethtool
> properly.
This looks good to me. Please take a read on
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
The Subject line should indicate the tree.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net v2] net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()
From: Andrew Lunn @ 2026-05-05 12:35 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Niklas Söderlund, Geert Uytterhoeven, Jakub Kicinski,
David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman, netdev,
linux-renesas-soc, linux-kernel, Shitalkumar Gandhi
In-Reply-To: <20260505123236.406000-1-shitalkumar.gandhi@cambiumnetworks.com>
On Tue, May 05, 2026 at 06:02:36PM +0530, Shitalkumar Gandhi wrote:
> of_get_child_by_name() takes a reference. The rtsn_reset() and
> rtsn_change_mode() failure paths jump to out_free_bus and leak
> mdio_node.
>
> Add out_put_node to drop it before falling through.
>
> Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN")
> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: eth: fbnic: Add pma read and write access
From: Paolo Abeni @ 2026-05-05 12:40 UTC (permalink / raw)
To: mike.marciniszyn, Alexander Duyck, Jakub Kicinski, kernel-team,
Andrew Lunn, David S. Miller, Eric Dumazet, Heiner Kallweit,
Russell King, Jacob Keller, Mohsin Bashir, Lee Trager,
Andrew Lunn
Cc: netdev, linux-kernel
In-Reply-To: <20260430150802.3521-4-mike.marciniszyn@gmail.com>
On 4/30/26 5:08 PM, mike.marciniszyn@gmail.com wrote:
> From: "Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>
>
> Document the MDIO interface topology with an ASCII diagram
> showing the MAC, PCS (MMD 3), FEC, Separated PMA (MMD 8), and PMD
> (MMD 1) blocks and their interconnects. The diagram illustrates how
> 4 lanes connect the MAC through PCS, FEC, and PMA, then narrow to
> 2 lanes at the PMD.
>
> The c45 read and write routines are enhanced to support
> read and write of the separated PMA for the fbnic.
>
> Co-developed-by: Alexander Duyck <alexanderduyck@fb.com>
> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
> Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
> ---
> v2:
> - no changes
> v1: https://lore.kernel.org/all/20260428172810.175077-5-mike.marciniszyn@gmail.com/
>
> drivers/net/ethernet/meta/fbnic/fbnic_csr.h | 1 +
> drivers/net/ethernet/meta/fbnic/fbnic_mdio.c | 71 ++++++++++++++++++++
> 2 files changed, 72 insertions(+)
>
> diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
> index 81794bd326e1..64b958df7774 100644
> --- a/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
> +++ b/drivers/net/ethernet/meta/fbnic/fbnic_csr.h
> @@ -805,6 +805,7 @@ enum {
> #define FBNIC_CSR_END_PCS 0x10668 /* CSR section delimiter */
>
> #define FBNIC_CSR_START_RSFEC 0x10800 /* CSR section delimiter */
> +#define FBNIC_RSFEC_CONTROL(n) (0x10800 + 8 * (n)) /* 0x42000 + 32*n */
Sashiko says:
---
With the introduction of the RSFEC memory space at 0x10800, does the bounds
check in fbnic_mdio_write_pcs() need to be updated to prevent clobbering
these new registers?
While not introduced by this patch, fbnic_mdio_write_pcs() currently
contains:
/* Allow access to both halves of PCS for 50R2 config */
if (addr > 2)
return;
When addr is 2, FBNIC_PCS_PAGE(2) evaluates to 0x10000 + 0x400 * 2, which
is 0x10800.
Since this overlaps with FBNIC_CSR_START_RSFEC, an MDIO write to MMD 3
(PCS) at address 2 could silently overwrite the newly managed RSFEC
control registers.
The read function fbnic_mdio_read_pcs() correctly uses if (addr >= 2) to
prevent this. Should the write function be updated to match?
---
Does not look blocking to me, but a follow-up could be needed.
/P
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: Add support for TX/RX channel interrupt
From: Andrew Lunn @ 2026-05-05 12:40 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: netdev, davem, kuba, pabeni, edumazet, andrew+netdev,
linux-kernel
In-Reply-To: <20260505024459.22463-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Mon, May 04, 2026 at 07:44:59PM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Enable TX/RX channel interrupt registration for MAC that interrupts CPU
> through shared peripheral interrupt (SPI).
Please take a read on https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
The Subject line needs to indicate the tree.
> int stmmac_get_platform_resources(struct platform_device *pdev,
> struct stmmac_resources *stmmac_res)
> {
> + char irq_name[9];
> + int i;
> + int irq;
> int ret;
Reverse Christmas Tree.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v4 2/4] veth: implement Byte Queue Limits (BQL) for latency reduction
From: Jesper Dangaard Brouer @ 2026-05-05 12:40 UTC (permalink / raw)
To: sashiko; +Cc: bpf, Netdev, Jakub Kicinski, kernel-team, Paolo Abeni,
Eric Dumazet
In-Reply-To: <20260502071828.616C3C19425@smtp.kernel.org>
On 02/05/2026 09.18, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Out-of-bounds array access on peer_dev->_tx in veth_poll() when local RX queues exceed peer TX queues.
> - [High] Disabling XDP permanently stops peer TX queues if they were backpressured (DRV_XOFF leak).
> --
>
> commit 9bc3ed022846dda6dd5cc131e798f949f63f491f
> Author: Jesper Dangaard Brouer <hawk@kernel.org>
>
> veth: implement Byte Queue Limits (BQL) for latency reduction
>
> This commit adds byte queue limits support to the veth driver to provide
> qdiscs with feedback and reduce latency. It charges a fixed unit per
> packet rather than byte-based charging.
>
>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>> index e35df717e65e2..3de25ba34a906 100644
>> --- a/drivers/net/veth.c
>> +++ b/drivers/net/veth.c
>
> [ ... ]
>
>> @@ -975,7 +1016,7 @@ static int veth_poll(struct napi_struct *napi, int budget)
>> peer_txq = peer_dev ? netdev_get_tx_queue(peer_dev, queue_idx) : NULL;
>>
>> xdp_set_return_frame_no_direct();
>> - done = veth_xdp_rcv(rq, budget, &bq, &stats);
>> + done = veth_xdp_rcv(rq, budget, &bq, &stats, peer_txq);
>
> Could this lead to an out-of-bounds array access on the peer device's
> transmit queues?
>
> If a veth pair is configured asymmetrically, the local device might have
> more receive queues than the peer has transmit queues.
>
> If packets are redirected from another interface into a higher-indexed
> receive queue, the poll function will run with a queue_idx greater than or
> equal to peer_dev->real_num_tx_queues.
>
> Since netdev_get_tx_queue() performs a direct array access without bounds
> checking, peer_txq would point out-of-bounds. This out-of-bounds pointer is
> then passed into the new veth_xdp_rcv() code paths and accessed by
> netif_tx_queue_stopped().
>
> Should queue_idx be checked against peer_dev->real_num_tx_queues before
> fetching the transmit queue?
Yes, for the XDP redirect code path, which enqueues frames into the
peer's ptr_ring using smp_processor_id() % peer->real_num_rx_queues
as the ring index. Then this is actually possible.
It is not a bug introduced in this patchset, but given we access
peer_txq a bit earlier, then a fix for this is needed as part of this
patchset. I have prepared a patch that fixes this.
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index e35df717e65e..0cfb19b760dd 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -972,7 +972,8 @@ static int veth_poll(struct napi_struct *napi, int
budget)
/* NAPI functions as RCU section */
peer_dev = rcu_dereference_check(priv->peer,
rcu_read_lock_bh_held());
- peer_txq = peer_dev ? netdev_get_tx_queue(peer_dev, queue_idx) :
NULL;
+ peer_txq = (peer_dev && queue_idx < peer_dev->real_num_tx_queues) ?
+ netdev_get_tx_queue(peer_dev, queue_idx) : NULL;
> [ ... ]
>
>> @@ -1091,6 +1133,17 @@ static void veth_napi_del_range(struct net_device *dev, int start, int end)
>> ptr_ring_cleanup(&rq->xdp_ring, veth_ptr_free);
>> }
>>
>> + /* Reset BQL on peer's txqs: remaining ring items were freed above
>> + * without BQL completion, so DQL state must be reset.
>> + */
>> + peer = rtnl_dereference(priv->peer);
>> + if (peer) {
>> + int peer_end = min(end, (int)peer->real_num_tx_queues);
>> +
>> + for (i = start; i < peer_end; i++)
>> + netdev_tx_reset_queue(netdev_get_tx_queue(peer, i));
>> + }
>
> Does this cleanup leave peer transmit queues permanently stopped if they
> were backpressured when xdp was disabled?
>
> When the ptr_ring is full, veth_xmit() stops the transmit queue using
> netif_tx_stop_queue(), which sets the __QUEUE_STATE_DRV_XOFF flag.
>
> While netdev_tx_reset_queue() successfully clears the newly added
> __QUEUE_STATE_STACK_XOFF flag, it does not clear __QUEUE_STATE_DRV_XOFF.
> If a queue was backpressured exactly when xdp is disabled, it appears it
> would remain locked forever.
>
> Would it be appropriate to wake the queues using netif_tx_wake_queue() or
> explicitly clear the __QUEUE_STATE_DRV_XOFF flag during this cleanup?
The watchdog timer in this patchset will call netif_tx_wake_queue().
So, we would recover from this unlikely case. I guess there is no harm
in adding a netif_tx_wake_queue() call here (but we should likely guard
it with netif_running(dev)).
--Jesper
^ permalink raw reply related
* Re: [PATCH net-next v2] rtase: Fix flow control configuration
From: Andrew Lunn @ 2026-05-05 12:43 UTC (permalink / raw)
To: Justin Lai
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, linux-kernel,
netdev, horms, pkshih, larry.chiu
In-Reply-To: <20260505064121.31286-1-justinlai0215@realtek.com>
On Tue, May 05, 2026 at 02:41:21PM +0800, Justin Lai wrote:
> The hardware has two sets of registers controlling TX/RX flow control.
> The effective flow control state is determined by the logical OR of
> these two sets of bits.
Odd design.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] net: phy: dp83867: add MDI-X management
From: Luca Ellero @ 2026-05-05 12:27 UTC (permalink / raw)
Cc: Luca Ellero, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, linux-kernel
ethtool on this phy device always reports "MDI-X: Unknown" and doesn't
support forcing it to on or off.
This patch adds support for reading/forcing MDI-X mode from ethtool
properly.
Signed-off-by: Luca Ellero <l.ellero@asem.it>
---
drivers/net/phy/dp83867.c | 60 +++++++++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 3fb2293f568f..88255e92b4cd 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -103,6 +103,10 @@
#define DP83867_PHYCR_RX_FIFO_DEPTH_MASK GENMASK(13, 12)
#define DP83867_PHYCR_SGMII_EN BIT(11)
#define DP83867_PHYCR_FORCE_LINK_GOOD BIT(10)
+#define DP83867_PHYCR_MDIX_MASK GENMASK(6, 5)
+#define DP83867_PHYCR_MDIX_MDI (0x0 << 5)
+#define DP83867_PHYCR_MDIX_MDIX (0x1 << 5)
+#define DP83867_PHYCR_MDIX_AUTO (0x3 << 5)
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_MAX 0xf
@@ -123,6 +127,10 @@
#define DP83867_PHYSTS_100 BIT(14)
#define DP83867_PHYSTS_DUPLEX BIT(13)
#define DP83867_PHYSTS_LINK BIT(10)
+#define DP83867_PHYSTS_MDIX_CD BIT(9)
+#define DP83867_PHYSTS_MDIX_AB BIT(8)
+#define DP83867_PHYSTS_MDIX_MASK (DP83867_PHYSTS_MDIX_AB | \
+ DP83867_PHYSTS_MDIX_CD)
/* CFG2 bits */
#define DP83867_DOWNSHIFT_EN (BIT(8) | BIT(9))
@@ -391,6 +399,22 @@ static int dp83867_read_status(struct phy_device *phydev)
else
phydev->speed = SPEED_10;
+ if (!(status & DP83867_PHYSTS_LINK)) {
+ phydev->mdix = ETH_TP_MDI_INVALID;
+ } else {
+ switch (status & DP83867_PHYSTS_MDIX_MASK) {
+ case 0:
+ phydev->mdix = ETH_TP_MDI;
+ break;
+ case DP83867_PHYSTS_MDIX_MASK:
+ phydev->mdix = ETH_TP_MDI_X;
+ break;
+ default:
+ phydev->mdix = ETH_TP_MDI_INVALID;
+ break;
+ }
+ }
+
return 0;
}
@@ -714,6 +738,8 @@ static int dp83867_config_init(struct phy_device *phydev)
struct dp83867_private *dp83867 = phydev->priv;
int ret, val, bs;
+ phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
+
/* Force speed optimization for the PHY even if it strapped */
ret = phy_modify(phydev, DP83867_CFG2, DP83867_DOWNSHIFT_EN,
DP83867_DOWNSHIFT_EN);
@@ -873,6 +899,39 @@ static int dp83867_config_init(struct phy_device *phydev)
return 0;
}
+static int dp83867_config_mdix(struct phy_device *phydev, u8 ctrl)
+{
+ int val;
+
+ switch (ctrl) {
+ case ETH_TP_MDI:
+ val = DP83867_PHYCR_MDIX_MDI;
+ break;
+ case ETH_TP_MDI_X:
+ val = DP83867_PHYCR_MDIX_MDIX;
+ break;
+ case ETH_TP_MDI_AUTO:
+ val = DP83867_PHYCR_MDIX_AUTO;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return phy_modify(phydev, MII_DP83867_PHYCTRL,
+ DP83867_PHYCR_MDIX_MASK, val);
+}
+
+static int dp83867_config_aneg(struct phy_device *phydev)
+{
+ int ret;
+
+ ret = dp83867_config_mdix(phydev, phydev->mdix_ctrl);
+ if (ret)
+ return ret;
+
+ return genphy_config_aneg(phydev);
+}
+
static int dp83867_phy_reset(struct phy_device *phydev)
{
int err;
@@ -1127,6 +1186,7 @@ static struct phy_driver dp83867_driver[] = {
.probe = dp83867_probe,
.config_init = dp83867_config_init,
+ .config_aneg = dp83867_config_aneg,
.soft_reset = dp83867_phy_reset,
.read_status = dp83867_read_status,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] vsock/virtio: fix vsockmon info leak in non-linear tap copy
From: Stefano Garzarella @ 2026-05-05 12:44 UTC (permalink / raw)
To: Paolo Abeni, Arseniy Krasnov, Bobby Eshleman
Cc: stefanha, netdev, linux-kernel, mst, jasowang, xuanzhuo, eperezma,
davem, edumazet, kuba, horms, Yiqi Sun, kvm, virtualization
In-Reply-To: <f4e52dcd-59ba-4c2e-9936-49cf27528b21@redhat.com>
CCing Arseniy and Bobby.
On Tue, May 05, 2026 at 12:26:21PM +0200, Paolo Abeni wrote:
>On 4/30/26 9:11 AM, Yiqi Sun wrote:
>> vsockmon mirrors packets through virtio_transport_build_skb(), which
>> builds a new skb and copies the payload into it. For non-linear skbs,
>> this goes through virtio_transport_copy_nonlinear_skb().
>>
>> Helper manually initializes a iov_iter, but leaves iov_iter.count unset.
>> As a result, skb_copy_datagram_iter() sees zero writable bytes
>> in the destination iterator and copies no payload data.
>>
>> This becomes an info leak because virtio_transport_build_skb() has
>> already reserved payload_len bytes in the new skb with skb_put(). The
>> skb is then returned to the tap path with that payload area still
>> uninitialized, so userspace reading from a vsockmon device can observe
>> heap contents and potentially kernel address.
>>
>> Fix it by initializing iov_iter.count to the number of bytes to copy.
>>
>> Fixes: 4b0bf10eb077 ("vsock/virtio: non-linear skb handling for tap")
>> Signed-off-by: Yiqi Sun <sunyiqixm@gmail.com>
>> ---
>> net/vmw_vsock/virtio_transport_common.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>> index 416d533f493d..6b26ee57ccab 100644
>> --- a/net/vmw_vsock/virtio_transport_common.c
>> +++ b/net/vmw_vsock/virtio_transport_common.c
>> @@ -152,7 +152,7 @@ static void virtio_transport_copy_nonlinear_skb(const struct sk_buff *skb,
>> iov_iter.nr_segs = 1;
>>
>> to_copy = min_t(size_t, len, skb->len);
>> -
>> + iov_iter.count = to_copy;
>> skb_copy_datagram_iter(skb, VIRTIO_VSOCK_SKB_CB(skb)->offset,
>> &iov_iter, to_copy);
>
>@Stefano, @Stefan, the patch LGTM, but sashiko pointed out to a
>pre-existing issue you should probably want to address:
>
>> to_copy = min_t(size_t, len, skb->len);
>Does this length calculation account for the offset when a packet is
>split across multiple transmissions?
>If a packet is requeued, VIRTIO_VSOCK_SKB_CB(skb)->offset is increased,
>but to_copy still evaluates to the full length of the skb.
Yep, I just checked and vhost-vsock is the only place where we call
virtio_transport_deliver_tap_pkt() wiht an offset != 0, but I agree that
we should also fix it.
Looking better in net/vmw_vsock/virtio_transport_common.c I think this
is a regression, indeed we have this comment in
virtio_transport_build_skb():
/* A packet could be split to fit the RX buffer, so we can retrieve
* the payload length from the header and the buffer pointer taking
* care of the offset in the original packet.
*/
pkt_hdr = virtio_vsock_hdr(pkt);
Before commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with
sk_buff") we read the payload lenght from the header that is always set
to the right value before delivering the packet to the tap.
From that commit, we don't to consider the offset anymore since we
started to use `len` from the skb, so IMO we should go back to what we
did before it, I mean:
payload_len = le32_to_cpu(pkt->hdr.len);
@Bobby do you remember why we did that change? Or if you see any issue
going back to what we did initially?
Also IMO we should avoid to set all the iov_iter fields by hand and
start to use iov_iter_kvec(). Plus, we can just use
skb_copy_datagram_iter() in any case, like we already do in vhost-vsock,
since it already handles linear vs non linear.
At the end I mean something like this:
@@ -171,7 +150,7 @@ static struct sk_buff *virtio_transport_build_skb(void *opaque)
* care of the offset in the original packet.
*/
pkt_hdr = virtio_vsock_hdr(pkt);
- payload_len = pkt->len;
+ payload_len = le32_to_cpu(pkt_hdr->len);
skb = alloc_skb(sizeof(*hdr) + sizeof(*pkt_hdr) + payload_len,
GFP_ATOMIC);
@@ -214,13 +193,17 @@ static struct sk_buff *virtio_transport_build_skb(void *opaque)
skb_put_data(skb, pkt_hdr, sizeof(*pkt_hdr));
if (payload_len) {
- if (skb_is_nonlinear(pkt)) {
- void *data = skb_put(skb, payload_len);
+ struct iov_iter iov_iter;
+ struct kvec kvec;
+ void *data = skb_put(skb, payload_len);
- virtio_transport_copy_nonlinear_skb(pkt, data, payload_len);
- } else {
- skb_put_data(skb, pkt->data, payload_len);
- }
+ kvec.iov_base = data;
+ kvec.iov_len = payload_len;
+ iov_iter_kvec(&iov_iter, READ, &kvec, 1, payload_len);
+
+ skb_copy_datagram_iter(pkt,
+ VIRTIO_VSOCK_SKB_CB(pkt)->offset,
+ &iov_iter, payload_len);
}
return skb;
And removing virtio_transport_copy_nonlinear_skb().
If you agree, I can send a proper series with these changes that should
fix the issue reported by Yiqi Sun introduced by commit 4b0bf10eb077
("vsock/virtio: non-linear skb handling for tap") and the issue
introduced by commit 71dc9ec9ac7d ("virtio/vsock: replace
virtio_vsock_pkt with sk_buff").
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH 1/3 net-next v3] ipv4: centralize devconf sysctl handling
From: Nicolas Dichtel @ 2026-05-05 12:46 UTC (permalink / raw)
To: Fernando Fernandez Mancera, netdev
Cc: linux-kselftest, horms, pabeni, kuba, edumazet, davem, idosch,
dsahern
In-Reply-To: <20260504123143.6284-1-fmancera@suse.de>
Le 04/05/2026 à 14:31, Fernando Fernandez Mancera a écrit :
> The logic for handling IPv4 devconf sysctls is scattered. Notification
> and cache flushes are managed in devinet_conf_proc(), while a separate
> ipv4_doint_and_flush() function and DEVINET_SYSCTL_FLUSHING_ENTRY macro
> is used for properties that solely require a cache flush.
>
> This patch refactors the sysctl handling by introducing a centralized
> helper, devinet_conf_post_set(). This new function evaluates the changed
> attribute and handles all necessary operations like triggering netlink
> notifications. It returns a boolean indicating whether a routing cache
> flush is required.
>
> Note that the boolean is necessary as this function will be re-used for
> netlink IPv4 devconf handling where the cache flushing must wait until
> all the attributes have been processed.
>
> Finally, this is introducing a small change in behavior for
> IPV4_DEVCONF_ROUTE_LOCALNET. As commit d0daebc3d622 ("ipv4: Add
> interface option to enable routing of 127.0.0.0/8") intended, the cache
> flush should only be performed when ROUTE_LOCALNET changes from 1 to 0.
> Unfortunately, this was not true because while implementing it the
> DEVINET_SYSCTL_FLUSHING_ENTRY was used for the attribute, making the
> code related to it on devinet_conf_proc() dead.
>
> IPV4_DEVCONF_FORWARDING is still being handled separately as it requires
> more operations.
>
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH 2/3 net-next v3] ipv4: handle devconf post-set actions on netlink updates
From: Nicolas Dichtel @ 2026-05-05 12:46 UTC (permalink / raw)
To: Fernando Fernandez Mancera, netdev
Cc: linux-kselftest, horms, pabeni, kuba, edumazet, davem, idosch,
dsahern
In-Reply-To: <20260504123143.6284-2-fmancera@suse.de>
Le 04/05/2026 à 14:31, Fernando Fernandez Mancera a écrit :
> When IPv4 device configuration parameters are updated via netlink, the
> kernel currently only updates the value. This bypasses several
> post-modification actions that occur when these same parameters are
> updated via sysctl, such as flushing the routing cache or emitting
> RTM_NEWNETCONF notifications.
>
> This patch addresses the inconsistency by calling the
> devinet_conf_post_set() helper inside inet_set_link_af(). If a flush is
> required, we defer it until the netlink attribute parsing loop
> completes.
>
> This ensures consistent behavior and side-effects for devconf changes,
> regardless of whether they are initiated via sysctl or netlink.
>
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox