* [PATCH v3 0/3] ksz87xx: add support for low-loss cable equalizer errata
From: Fidelio Lawson @ 2026-04-14 9:12 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
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 provides two workarounds, each requiring a write to a different
indirect PHY register access mechanism.
The workaround requires programming internal PHY/DSP registers located in the
LinkMD table, accessed through the KSZ8 indirect register mechanism. Since these
registers belong to the switch address space and are not directly accessible
from a standalone PHY driver, the erratum control is modeled as a vendor-specific
Clause 22 PHY register, virtualized by the KSZ8 DSA driver.
Reads and writes to this register are intercepted by ksz8_r_phy() /
ksz8_w_phy() and translated into the required TABLE_LINK_MD_V indirect accesses.
The erratum affects the shared PHY analog front-end and therefore applies
globally to the switch.
The control register defines the following modes:
0: disabled (default behavior)
1: EQ training workaround
2: LPF 90 MHz
3: LPF 62 MHz
4: LPF 55 MHz
5: LPF 44 MHz
The register can be read and written from userspace via a phy tunable.
Note that current ethtool userspace only supports a fixed set of PHY tunables;
vendor-specific tunables may require either phytool or a newer userspace extension.
This series is based on Linux v7.0-rc1.
Signed-off-by: Fidelio Lawson <fidelio.lawson@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 PHY tunable
net: phy: micrel: expose KSZ87xx low-loss erratum via PHY tunable
drivers/net/dsa/microchip/ksz8.c | 45 ++++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz8_reg.h | 36 ++++++++++++++++++++++++++-
drivers/net/dsa/microchip/ksz_common.h | 3 +++
drivers/net/phy/micrel.c | 39 +++++++++++++++++++++++++++++
include/uapi/linux/ethtool.h | 1 +
net/ethtool/common.c | 1 +
net/ethtool/ioctl.c | 1 +
7 files changed, 125 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 v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio Lawson @ 2026-04-14 9:12 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
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <20260414-ksz87xx_errata_low_loss_connections-v3-0-0e3838ca98c9@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.
The affected registers are part of the switch address space and are not
directly accessible from the PHY driver. To keep the PHY-facing API
clean and avoid leaking switch-specific details, model this errata
control as vendor-specific Clause 22 PHY registers.
A vendor-specific Clause 22 PHY register is introduced as a mode
selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
translate accesses to these bits into the appropriate indirect
TABLE_LINK_MD_V accesses.
The control register defines the following modes:
0: disabled (default behavior)
1: EQ training workaround
2: LPF 90 MHz
3: LPF 62 MHz
4: LPF 55 MHz
5: LPF 44 MHz
Workaround 1: Adjusts the DSP EQ training behavior via LinkMD register
0x3C. Widens and optimizes the DSP EQ compensation range,
and is expected to solve most short/low-loss cable issues.
Workaround 2: for the cases where Workaround 1 is not sufficient.
This one adjusts the receiver low-pass filter bandwidth, effectively
reducing the high-frequency component of the received signal
The register is accessible through standard PHY read/write operations
(e.g. phytool), without requiring any switch-specific userspace
interface. This allows robust link establishment on short or
low-loss cabling without requiring DTS properties and without
constraining hardware design choices.
The erratum affects the shared PHY analog front-end and therefore
applies globally to the switch.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
drivers/net/dsa/microchip/ksz8.c | 45 ++++++++++++++++++++++++++++++++++
drivers/net/dsa/microchip/ksz8_reg.h | 36 ++++++++++++++++++++++++++-
drivers/net/dsa/microchip/ksz_common.h | 3 +++
3 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
index c354abdafc1b..596c85654f24 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1058,6 +1058,11 @@ int ksz8_r_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 *val)
if (ret)
return ret;
+ break;
+ case PHY_REG_KSZ87XX_LOW_LOSS:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+ data = dev->low_loss_wa_mode;
break;
default:
processed = false;
@@ -1271,6 +1276,46 @@ int ksz8_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val)
if (ret)
return ret;
break;
+ case PHY_REG_KSZ87XX_LOW_LOSS:
+ if (!ksz_is_ksz87xx(dev))
+ return -EOPNOTSUPP;
+
+ switch (val & PHY_KSZ87XX_LOW_LOSS_MASK) {
+ case PHY_LOW_LOSS_ERRATA_DISABLED:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+ KSZ87XX_EQ_TRAIN_DEFAULT);
+ if (!ret)
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD,
+ KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_LOW_LOSS_LPF_90MHZ);
+ break;
+ case KSZ87XX_LOW_LOSS_EQ_TRAIN:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+ KSZ87XX_EQ_TRAIN_LOW_LOSS);
+ break;
+ case KSZ87XX_LOW_LOSS_LPF_90MHZ:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_90MHZ);
+ break;
+ case KSZ87XX_LOW_LOSS_LPF_62MHZ:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_62MHZ);
+ break;
+ case KSZ87XX_LOW_LOSS_LPF_55MHZ:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_55MHZ);
+ break;
+ case KSZ87XX_LOW_LOSS_LPF_44MHZ:
+ ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+ KSZ87XX_PHY_LPF_44MHZ);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (!ret)
+ dev->low_loss_wa_mode = val & PHY_KSZ87XX_LOW_LOSS_MASK;
+ return ret;
default:
break;
}
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h
index 332408567b47..4e02e044339c 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -202,6 +202,10 @@
#define REG_PORT_3_STATUS_0 0x38
#define REG_PORT_4_STATUS_0 0x48
+/* KSZ87xx LinkMD registers (TABLE_LINK_MD_V) */
+#define KSZ87XX_REG_EQ_TRAIN 0x3C
+#define KSZ87XX_REG_PHY_LPF 0x4C
+
/* For KSZ8765. */
#define PORT_REMOTE_ASYM_PAUSE BIT(5)
#define PORT_REMOTE_SYM_PAUSE BIT(4)
@@ -342,7 +346,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 +733,36 @@
#define PHY_POWER_SAVING_ENABLE BIT(2)
#define PHY_REMOTE_LOOPBACK BIT(1)
+/* Equalizer low-loss workaround */
+#define PHY_REG_KSZ87XX_LOW_LOSS 0x1C
+#define PHY_KSZ87XX_LOW_LOSS_MASK GENMASK(2, 0)
+
+/* KSZ87xx low-loss EQ mode selector (vendor-specific PHY reg 0x1c)
+ *
+ * Values:
+ * 0: disabled (default behavior)
+ * 1: EQ training workaround
+ * 2: LPF 90 MHz
+ * 3: LPF 62 MHz
+ * 4: LPF 55 MHz
+ * 5: LPF 44 MHz
+ */
+#define PHY_LOW_LOSS_ERRATA_DISABLED 0
+#define KSZ87XX_LOW_LOSS_EQ_TRAIN 1
+#define KSZ87XX_LOW_LOSS_LPF_90MHZ 2
+#define KSZ87XX_LOW_LOSS_LPF_62MHZ 3
+#define KSZ87XX_LOW_LOSS_LPF_55MHZ 4
+#define KSZ87XX_LOW_LOSS_LPF_44MHZ 5
+
+#define KSZ87XX_EQ_TRAIN_DEFAULT 0x0A
+#define KSZ87XX_EQ_TRAIN_LOW_LOSS 0x15
+
+/* LPF bandwidth bits [7:6]: 00 = 90MHz, 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
+
/* 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..16a6074ea4b4 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -219,6 +219,9 @@ struct ksz_device {
* the switch’s internal PHYs, bypassing the main SPI interface.
*/
struct mii_bus *parent_mdio_bus;
+
+ /* Equalizer low-loss workaround tunable */
+ u8 low_loss_wa_mode; /* KSZ87xx low-loss EQ/LPF mode selector (0-5) */
};
/* List of supported models */
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/3] net: ethtool: add KSZ87xx low-loss PHY tunable
From: Fidelio Lawson @ 2026-04-14 9:12 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
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <20260414-ksz87xx_errata_low_loss_connections-v3-0-0e3838ca98c9@exotec.com>
Introduce a new PHY tunable identifier,
ETHTOOL_PHY_KSZ87XX_LOW_LOSS, to allow userspace to control the
KSZ87xx low-loss cable erratum through the ethtool PHY tunable
interface.
KSZ87xx switches integrate embedded PHYs whose receiver behavior may
require specific equalizer or low-pass filter adjustments when used
with short or low-loss Ethernet cables, as described in Microchip
errata DS80000687C (Module 3). The new tunable provides a userspace
interface for selecting the desired operating mode.
The tunable uses a u8 value and is vendor-specific by design. The
actual handling is implemented by the corresponding PHY driver.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
include/uapi/linux/ethtool.h | 1 +
net/ethtool/common.c | 1 +
net/ethtool/ioctl.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index b74b80508553..5c539e1bca4b 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -295,6 +295,7 @@ enum phy_tunable_id {
* Add your fresh new phy tunable attribute above and remember to update
* phy_tunable_strings[] in net/ethtool/common.c
*/
+ ETHTOOL_PHY_KSZ87XX_LOW_LOSS,
__ETHTOOL_PHY_TUNABLE_COUNT,
};
diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index e252cf20c22f..e1c98ce66093 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c
@@ -101,6 +101,7 @@ 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_KSZ87XX_LOW_LOSS] = "phy-ksz87xx-low-loss",
};
#define __LINK_MODE_NAME(speed, type, duplex) \
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index ff4b4780d6af..9e7bd887acf5 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -3109,6 +3109,7 @@ 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_KSZ87XX_LOW_LOSS:
if (tuna->len != sizeof(u8) ||
tuna->type_id != ETHTOOL_TUNABLE_U8)
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 3/3] net: phy: micrel: expose KSZ87xx low-loss erratum via PHY tunable
From: Fidelio Lawson @ 2026-04-14 9:12 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
Cc: Woojung Huh, netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <20260414-ksz87xx_errata_low_loss_connections-v3-0-0e3838ca98c9@exotec.com>
Expose the KSZ87xx low-loss cable erratum control through the PHY
tunable interface.
KSZ87xx switches integrate embedded PHYs whose receiver analog front-end
may require specific equalizer or low-pass filter adjustments when used
with short or low-loss Ethernet cables, as described in Microchip errata
DS80000687C (Module 3).
Implement get_tunable / set_tunable callbacks in the Micrel PHY driver
for KSZ87xx devices, mapping the ETHTOOL_PHY_KSZ87XX_LOW_LOSS tunable
to a vendor-specific Clause 22 PHY register. Accesses are routed through
standard phy_read() / phy_write() operations and translated by the KSZ8
DSA driver into the appropriate internal LinkMD table updates.
The tunable uses a u8 mode selector, allowing userspace to select
between the documented equalizer and LPF bandwidth configurations.
Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
drivers/net/phy/micrel.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index c6b011a9d636..7cbca6a7ed84 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -287,6 +287,11 @@
/* 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_LOW_LOSS 0x1c
+#define KSZ87XX_LOW_LOSS_MAX 5
+
/* 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 +945,38 @@ 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_KSZ87XX_LOW_LOSS:
+ ret = phy_read(phydev, MII_KSZ87XX_LOW_LOSS);
+ 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_KSZ87XX_LOW_LOSS:
+ if (val > KSZ87XX_LOW_LOSS_MAX)
+ return -EINVAL;
+ return phy_write(phydev, MII_KSZ87XX_LOW_LOSS, 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 +6846,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.53.0
^ permalink raw reply related
* [syzbot] [ppp?] KMSAN: uninit-value in ppp_sync_receive (4)
From: syzbot @ 2026-04-14 9:14 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, linux-kernel, linux-ppp,
netdev, pabeni, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 9a9c8ce300cd Merge tag 'kbuild-fixes-7.0-4' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=112a874e580000
kernel config: https://syzkaller.appspot.com/x/.config?x=963de479f54c6dbb
dashboard link: https://syzkaller.appspot.com/bug?extid=88679c919eb801bd16f8
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3e2ad23d804a/disk-9a9c8ce3.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a3dde4990296/vmlinux-9a9c8ce3.xz
kernel image: https://storage.googleapis.com/syzbot-assets/256e0a89d22c/bzImage-9a9c8ce3.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+88679c919eb801bd16f8@syzkaller.appspotmail.com
=====================================================
BUG: KMSAN: uninit-value in ppp_sync_input drivers/net/ppp/ppp_synctty.c:684 [inline]
BUG: KMSAN: uninit-value in ppp_sync_receive+0x626/0xfa0 drivers/net/ppp/ppp_synctty.c:334
ppp_sync_input drivers/net/ppp/ppp_synctty.c:684 [inline]
ppp_sync_receive+0x626/0xfa0 drivers/net/ppp/ppp_synctty.c:334
tty_ldisc_receive_buf+0x1f7/0x2c0 drivers/tty/tty_buffer.c:391
tty_port_default_receive_buf+0xd7/0x1a0 drivers/tty/tty_port.c:37
receive_buf drivers/tty/tty_buffer.c:445 [inline]
flush_to_ldisc+0x43e/0xe40 drivers/tty/tty_buffer.c:495
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb82/0x1e80 kernel/workqueue.c:3359
worker_thread+0xee4/0x1590 kernel/workqueue.c:3440
kthread+0x53f/0x600 kernel/kthread.c:436
ret_from_fork+0x20f/0x910 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4545 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_noprof+0x486/0x1680 mm/slub.c:5272
kmalloc_noprof include/linux/slab.h:954 [inline]
tty_buffer_alloc drivers/tty/tty_buffer.c:180 [inline]
__tty_buffer_request_room+0x3d4/0x7a0 drivers/tty/tty_buffer.c:273
__tty_insert_flip_string_flags+0x157/0x6e0 drivers/tty/tty_buffer.c:309
tty_insert_flip_char include/linux/tty_flip.h:77 [inline]
uart_insert_char+0x368/0x930 drivers/tty/serial/serial_core.c:3431
serial8250_read_char+0x1ba/0x670 drivers/tty/serial/8250/8250_port.c:1643
serial8250_rx_chars drivers/tty/serial/8250/8250_port.c:1660 [inline]
serial8250_handle_irq_locked+0x6d4/0xa40 drivers/tty/serial/8250/8250_port.c:1820
serial8250_handle_irq+0x187/0x730 drivers/tty/serial/8250/8250_port.c:1841
serial8250_default_handle_irq+0x116/0x370 drivers/tty/serial/8250/8250_port.c:1855
serial8250_interrupt+0xcb/0x420 drivers/tty/serial/8250/8250_core.c:86
__handle_irq_event_percpu+0x13c/0xf90 kernel/irq/handle.c:209
handle_irq_event_percpu kernel/irq/handle.c:246 [inline]
handle_irq_event+0xe0/0x2a0 kernel/irq/handle.c:263
handle_edge_irq+0x2a9/0xb30 kernel/irq/chip.c:855
generic_handle_irq_desc include/linux/irqdesc.h:186 [inline]
handle_irq arch/x86/kernel/irq.c:262 [inline]
call_irq_handler arch/x86/kernel/irq.c:-1 [inline]
__common_interrupt+0x9d/0x180 arch/x86/kernel/irq.c:333
common_interrupt+0x4c/0xb0 arch/x86/kernel/irq.c:326
asm_common_interrupt+0x2b/0x40 arch/x86/include/asm/idtentry.h:688
CPU: 0 UID: 0 PID: 35 Comm: kworker/u8:2 Tainted: G W L syzkaller #0 PREEMPT(full)
Tainted: [W]=WARN, [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Workqueue: events_unbound flush_to_ldisc
=====================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH iwl-next 4/10] ice: reorder ice_flash_info fields to eliminate padding
From: Simon Horman @ 2026-04-14 9:16 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller
In-Reply-To: <20260410074921.1254213-5-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:15AM +0200, Aleksandr Loktionov wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> The ice_flash_info structure has a u16 sr_words field before a u32
> flash_size value. This creates a 2-byte hole as well as 3 bytes of
> padding at the end of the structure due to the blank_nvm_mode bitfield.
>
> Re-order the structure to place flash_size first, which gives a better
> layout and reduces padding.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] selftests/bpf: verify syncookie statistics in tcp_custom_syncookie
From: Paolo Abeni @ 2026-04-14 9:17 UTC (permalink / raw)
To: Kuniyuki Iwashima, Jiayuan Chen, Eric Dumazet, Daniel Borkmann
Cc: netdev, Neal Cardwell, David S. Miller, Jakub Kicinski,
Simon Horman, David Ahern, Alexei Starovoitov, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Shuah Khan, linux-kernel, bpf, linux-kselftest
In-Reply-To: <6b22a595-cd65-42ec-b332-c835273bc174@redhat.com>
On 4/14/26 11:08 AM, Paolo Abeni wrote:
> On 4/14/26 7:50 AM, Kuniyuki Iwashima wrote:
>> On Fri, Apr 10, 2026 at 6:32 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>>>
>>> Add read_tcpext_snmp() helper to network_helpers which reads a
>>> TcpExt SNMP counter via nstat, and use it in the tcp_custom_syncookie
>>> test to verify that LINUX_MIB_SYNCOOKIESRECV is incremented and
>>> LINUX_MIB_SYNCOOKIESFAILED stays unchanged across a successful
>>> BPF custom syncookie validation.
>>>
>>> The delta is captured between start_server() and accept(), which
>>> covers the full SYN/ACK/cookie-check path for one connection.
>>>
>>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>>> ---
>>> tools/testing/selftests/bpf/network_helpers.c | 22 +++++++++++++++++++
>>> tools/testing/selftests/bpf/network_helpers.h | 1 +
>>> .../bpf/prog_tests/tcp_custom_syncookie.c | 20 +++++++++++++++++
>>
>> As you touch bpf selftest helper files, please rebase on bpf-next
>> to avoid possible conflicts and tag bpf-next in the Subject.
>
> To hopefully minimize the conflicts handling I'm going to apply patch
> 1/2 to net-next. Please resubmit patch 2/2 to bpf-next after the
> relevant net core reach there.
Uhmm... the original feature went through the bpf tree, so I guess both
patches could/should via bpf-next. Hopefully conflict into the tcp code
should be minimal.
@Eric, @Daniel: please LMK if you prefer otherwise.
/P
^ permalink raw reply
* Re: [PATCH] netfilter: nfnetlink_osf: fix null-ptr-deref in nf_osf_ttl
From: Pablo Neira Ayuso @ 2026-04-14 9:19 UTC (permalink / raw)
To: Kito Xu (veritas501)
Cc: Florian Westphal, Phil Sutter, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman,
Fernando Fernandez Mancera, netfilter-devel, coreteam, netdev,
linux-kernel
In-Reply-To: <20260414074556.2512750-1-hxzene@gmail.com>
On Tue, Apr 14, 2026 at 03:45:56PM +0800, Kito Xu (veritas501) wrote:
> diff --git a/net/netfilter/nfnetlink_osf.c b/net/netfilter/nfnetlink_osf.c
> index d64ce21c7b55..85dbd47dbbd4 100644
> --- a/net/netfilter/nfnetlink_osf.c
> +++ b/net/netfilter/nfnetlink_osf.c
> @@ -43,6 +43,9 @@ static inline int nf_osf_ttl(const struct sk_buff *skb,
> else if (ip->ttl <= f_ttl)
> return 1;
>
> + if (!in_dev)
> + return 0;
> +
I suggest you add this check a bit earlier:
diff --git a/net/netfilter/nfnetlink_osf.c b/net/netfilter/nfnetlink_osf.c
index 5d15651c74f0..e8069f4e139b 100644
--- a/net/netfilter/nfnetlink_osf.c
+++ b/net/netfilter/nfnetlink_osf.c
@@ -36,6 +36,9 @@ static inline int nf_osf_ttl(const struct sk_buff *skb,
const struct in_ifaddr *ifa;
int ret = 0;
+ if (!in_dev)
+ return 0;
+
if (ttl_check == NF_OSF_TTL_TRUE)
return ip->ttl == f_ttl;
if (ttl_check == NF_OSF_TTL_NOCHECK)
@@ -43,9 +46,6 @@ static inline int nf_osf_ttl(const struct sk_buff *skb,
else if (ip->ttl <= f_ttl)
return 1;
- if (!in_dev)
- return 0;
-
in_dev_for_each_ifa_rcu(ifa, in_dev) {
if (inet_ifa_match(ip->saddr, ifa)) {
ret = (ip->ttl == f_ttl);
Thanks!
^ permalink raw reply related
* Re: [RFC] Proposal: Add sysfs interface for PCIe TPH Steering Tag retrieval and configuration
From: fengchengwen @ 2026-04-14 9:30 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, Bjorn Helgaas, linux-rdma, linux-pci, netdev,
dri-devel, Keith Busch, Yochai Cohen, Yishai Hadas, Zhiping Zhang
In-Reply-To: <20260414085723.GR21470@unreal>
On 4/14/2026 4:57 PM, Leon Romanovsky wrote:
> On Tue, Apr 14, 2026 at 09:07:23AM +0800, fengchengwen wrote:
>> On 4/14/2026 3:19 AM, Leon Romanovsky wrote:
>>> On Mon, Apr 13, 2026 at 08:04:10PM +0800, fengchengwen wrote:
>>>> On 4/13/2026 6:01 PM, Leon Romanovsky wrote:
>>>>> On Fri, Apr 10, 2026 at 10:30:52PM +0800, fengchengwen wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I'm writing to propose adding a sysfs interface to expose and configure the
>>>>>> PCIe TPH
>>>>>> Steering Tag for PCIe devices, which is retrieved inside the kernel.
>>>>>>
>>>>>>
>>>>>> Background: The TPH Steering Tag is tightly coupled with both a PCIe device
>>>>>> (identified
>>>>>> by its BDF) and a CPU core. It can only be obtained in kernel mode. To allow
>>>>>> user-space
>>>>>> applications to fetch and set this value securely and conveniently, we need
>>>>>> a standard
>>>>>> kernel-to-user interface.
>>>>>>
>>>>>>
>>>>>> Proposed Solution: Add several sysfs attributes under each PCIe device's
>>>>>> sysfs directory:
>>>>>> 1. /sys/bus/pci/devices/<BDF>/tph_mode to query the TPH mode (interrupt or
>>>>>> device specific)
>>>>>> 2. /sys/bus/pci/devices/<BDF>/tph_enable to control the TPH feature
>>>>>> 3. /sys/bus/pci/devices/<BDF>/tph_st to support both read and write
>>>>>> operations, e.g.:
>>>>>> Read operation:
>>>>>> echo "cpu=3" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>>> cat /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>>> Write operation:
>>>>>> echo "index=10 st=123" > /sys/bus/pci/devices/0000:01:00.0/tph_st
>>>>>>
>>>>>>
>>>>>> The design strictly follows PCI subsystem sysfs standards and has the
>>>>>> following key properties:
>>>>>>
>>>>>> 1. Dynamic Visibility: The sysfs attributes will only be present for PCIe
>>>>>> devices that
>>>>>> support TPH Steering Tag. Devices without TPH capability will not show
>>>>>> these nodes,
>>>>>> avoiding unnecessary user confusion.
>>>>>>
>>>>>> 2. Permission Control: The attributes will use 0600 file permissions,
>>>>>> ensuring only
>>>>>> privileged root users can read or write them, which satisfies security
>>>>>> requirements
>>>>>> for hardware configuration interfaces.
>>>>>>
>>>>>> 3. Standard Implementation Location: The interface will be implemented in
>>>>>> drivers/pci/pci-sysfs.c, the canonical location for all PCI device sysfs
>>>>>> attributes,
>>>>>> ensuring consistency and maintainability within the PCI subsystem.
>>>>>>
>>>>>>
>>>>>> Why sysfs instead of alternatives like VFIO-PCI ioctl:
>>>>>>
>>>>>> - Universality: sysfs does not require binding the device to a special
>>>>>> driver such as
>>>>>> vfio-pci. It is available to any privileged user-space component,
>>>>>> including system
>>>>>> utilities, daemons, and monitoring tools.
>>>>>>
>>>>>> - Simplicity: Both user-space usage (cat/echo) and kernel implementation are
>>>>>> straightforward, reducing code complexity and long-term maintenance cost.
>>>>>>
>>>>>> - Design Alignment: TPH Steering Tag is a generic PCIe device feature, not
>>>>>> specific to
>>>>>> user-space drivers like DPDK or VFIO. Exposing it via sysfs matches the
>>>>>> kernel's
>>>>>> standard pattern for hardware capabilities.
>>>>>>
>>>>>>
>>>>>> I look forward to your comments about this design before submitting the
>>>>>> final patch.
>>>>>
>>>>> You need to explain more clearly why this write functionality is useful
>>>>> and necessary outside the VFIO/RDMA context:
>>>>> https://lore.kernel.org/all/20260324234615.3731237-1-zhipingz@meta.com/
>>>>>
>>>>> AFAIK, for non-VFIO TPH callers, kernel has enough knowledge to set
>>>>> right ST values.
>>>>>
>>>>> There are several comments regarding the implementation, but those can wait
>>>>> until the rationale behind the proposal is fully clarified.
>>>>
>>>> Thanks for your review and comments.
>>>>
>>>> Let me clarify the rationale behind this user-space sysfs interface:
>>>>
>>>> 1. VFIO is just one of the user-space device access frameworks.
>>>> There are many other in-kernel frameworks that expose devices
>>>> to user space, such as UIO, UACCE, etc., which may also require
>>>> TPH Steering Tag support.
>>>>
>>>> 2. The kernel can automatically program Steering Tags only when
>>>> the device provides a standard ST table in MSI-X or config space.
>>>> However, many devices implement vendor-specific or platform-specific
>>>> Steering Tag programming methods that cannot be fully handled
>>>> by the generic kernel code.
>>>>
>>>> 3. For such devices, user-space applications or framework drivers
>>>> need to retrieve and configure TPH Steering Tags directly.
>>>> A unified sysfs interface allows all user-space frameworks
>>>> (not just VFIO) to use a common, standard way to manage
>>>> TPH Steering Tags, rather than implementing duplicated logic
>>>> in each subsystem.
>>>>
>>>> This interface provides a uniform method for any user-space
>>>> device access solution to work with TPH, which is why I believe
>>>> it is useful and necessary beyond the VFIO/RDMA case.
>>>
>>> I understand the rationale for providing a read interface, for example for
>>> debugging, but I do not see any justification for a write interface.
>>
>> Thank you for the comment!
>>
>> As I explained, read interface is not only for debugging. It was used to
>> such device who don't declare ST location in MSI-X or config-space, the following
>> is Intel X710 NIC device's lspci output (only TPH part):
>>
>> Capabilities: [1a0 v1] Transaction Processing Hints
>> Device specific mode supported
>> No steering table available
>>
>> So we could not config the ST for device on kernel because it's vendor specific.
>> But we could configure ST by it's vendor user-space driver, in this case, we
>> should get ST from kernel to user-space.
>
> Vendor-specific, in the context of the PCI specification, does not mean the
> kernel cannot configure it. It simply means that the ST values are not
> stored in the ST table.
Thank you for the clarification!
I agree with your interpretation of "vendor-specific" in PCI spec terms—it
does not prevent the kernel from handling TPH in principle. However, the
real problem is that the kernel has no standardized way to know where or
how to program those vendor-specific ST values.
When a device reports "No steering table available" and operates in
device-specific mode, the method used to set ST values is entirely
device-specific and not covered by the PCI specification. If the device
is taken over to user-space by UIO framework (e.g. VFIO or IGB_UIO), the
generic kernel cannot infer the proper programming sequence or registers
for each vendor-specific implementation.
In these cases, the configuration must be done by the vendor’s
user-space driver, which is aware of the device’s private programming
model. But such a user-space driver still needs to obtain valid,
platform-provided ST values (from ACPI _DSM), which it cannot do
without a kernel interface.
This is why a read-only interface to retrieve ST values is still
needed: the kernel holds the valid platform tags, while the user-space
driver handles the device-specific programming.
Thanks
>
> Thanks
^ permalink raw reply
* Re: [PATCH iwl-next 5/10] ice: improve Add/Update VSI error messages in ice_vsi_init()
From: Simon Horman @ 2026-04-14 9:30 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: 'Simon Horman', intel-wired-lan, anthony.l.nguyen, netdev,
jacob.e.keller
In-Reply-To: <20260410074921.1254213-6-aleksandr.loktionov@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ice: improve Add/Update VSI error messages in ice_vsi_init()
The error messages emitted when Add VSI or Update VSI Admin
Queue commands fail are missing the VSI index and the last AQ
error code. Add both to match the pattern used elsewhere in
the driver for AQ-command failures, which helps narrow down
firmware issues without requiring debug logs.
> diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
> index 689c6025ea82e..0e79d66959d4f 100644
> --- a/drivers/net/ethernet/intel/ice/ice_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_lib.c
> @@ -1320,14 +1320,18 @@ static int ice_vsi_init(struct ice_vsi *vsi, u32 vsi_flags)
> if (vsi_flags & ICE_VSI_FLAG_INIT) {
> ret = ice_add_vsi(hw, vsi->idx, ctxt, NULL);
> if (ret) {
> - dev_err(dev, "Add VSI failed, err %d\n", ret);
> + dev_err(dev, "Add VSI %d failed, err %d aq_err %s\n",
> + vsi->idx, ret,
> + libie_aq_str(hw->adminq.sq_last_status));
Will this print a misleading "aq_err OK" if ice_add_vsi() fails for software
reasons?
For instance, if devm_kzalloc() fails inside ice_add_vsi(), it calls
ice_aq_free_vsi() to clean up before returning -ENOMEM:
int ice_add_vsi(...)
{
...
tmp_vsi_ctx = devm_kzalloc(ice_hw_to_dev(hw), ...
if (!tmp_vsi_ctx) {
ice_aq_free_vsi(hw, vsi_ctx, false, cd);
return -ENOMEM;
}
...
}
The successful ice_aq_free_vsi() call resets hw->adminq.sq_last_status to OK.
Since the log unconditionally prints sq_last_status, it will display the
-ENOMEM error alongside "aq_err OK".
Additionally, could reading hw->adminq.sq_last_status outside the Admin Queue
lock be racy? Could a concurrent AQ command overwrite the status before it
is printed?
> ret = -EIO;
> goto out;
> }
> } else {
> ret = ice_update_vsi(hw, vsi->idx, ctxt, NULL);
> if (ret) {
> - dev_err(dev, "Update VSI failed, err %d\n", ret);
> + dev_err(dev, "Update VSI %d failed, err %d aq_err %s\n",
> + vsi->idx, ret,
> + libie_aq_str(hw->adminq.sq_last_status));
A similar situation applies here. If ice_update_vsi() returns early due to an
invalid VSI handle, it returns -EINVAL without executing an AQ command. This
would result in printing whatever AQ status was left behind from a previous
command.
> ret = -EIO;
> goto out;
> }
^ permalink raw reply
* Re: [PATCH iwl-next 6/10] ice: increase OICR interrupt moderation rate to 20K interrupts/sec
From: Simon Horman @ 2026-04-14 9:33 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller
In-Reply-To: <20260410074921.1254213-7-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:17AM +0200, Aleksandr Loktionov wrote:
> The miscellaneous interrupt cause (OICR) is throttled to 8K
> interrupts per second (124 us minimum spacing). This interrupt
> handles VF mailbox messages and Tx timestamps, so the low rate
> imposes a minimum latency floor on both use-cases.
>
> Raise the rate to 20K interrupts per second (50 us minimum
> spacing) to allow lower latency handling for Tx timestamp
> bursts and high VF message rates.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net 1/1] net: bridge: use a stable FDB dst snapshot in RCU readers
From: Nikolay Aleksandrov @ 2026-04-14 9:33 UTC (permalink / raw)
To: Ren Wei, bridge, netdev
Cc: idosch, davem, edumazet, kuba, pabeni, horms, makita.toshiaki,
vyasevic, yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
zcliangcn
In-Reply-To: <6570fabb85ecadb8baaf019efe856f407711c7b9.1776043229.git.zcliangcn@gmail.com>
On 13/04/2026 12:08, Ren Wei wrote:
> From: Zhengchuan Liang <zcliangcn@gmail.com>
>
> Local FDB entries can be rewritten in place by `fdb_delete_local()`, which
> updates `f->dst` to another port or to `NULL` while keeping the entry
> alive. Several bridge RCU readers inspect `f->dst`, including
> `br_fdb_fillbuf()` through the `brforward_read()` sysfs path.
>
> These readers currently load `f->dst` multiple times and can therefore
> observe inconsistent values across the check and later dereference.
> In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change
> `f->dst` after the NULL check and before the `port_no` dereference,
> leading to a NULL-ptr-deref.
>
> Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each
> affected RCU reader and using that snapshot for the rest of the access
> sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()`
> with `WRITE_ONCE()` so the readers and writer use matching access patterns.
>
> Fixes: 960b589f86c7 ("bridge: Properly check if local fdb entry can be deleted in br_fdb_change_mac_address")
> Cc: stable@kernel.org
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/bridge/br_arp_nd_proxy.c | 8 +++++---
> net/bridge/br_fdb.c | 28 ++++++++++++++++++----------
> 2 files changed, 23 insertions(+), 13 deletions(-)
>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH iwl-next 7/10] ice: emit user-visible info message for non-contiguous ETS TC config
From: Simon Horman @ 2026-04-14 9:35 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Karen Ostrowska
In-Reply-To: <20260410074921.1254213-8-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:18AM +0200, Aleksandr Loktionov wrote:
> When the remote LLDP peer advertises a non-contiguous TC
> mapping the driver silently falls back to a default single-TC
> configuration. This leaves the user without any indication of
> why their DCB configuration was not honoured.
>
> Print an informational message at the entry of
> ice_dcb_noncontig_cfg() so the user knows ETS with
> non-contiguous TCs is not supported and that the driver
> has fallen back to defaults.
>
> Suggested-by: Karen Ostrowska <karen.ostrowska@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> index bd77f1c..1c53b09 100644
> --- a/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_dcb_lib.c
> @@ -712,6 +712,8 @@ static int ice_dcb_noncontig_cfg(struct ice_pf *pf)
> struct device *dev = ice_pf_to_dev(pf);
> int ret;
>
> + dev_info(dev, "Non-contiguous ETS TC config not supported, falling back to default single TC\n");
Sashiko points out that this seems to be controlled by user input.
If so, it should probably be rate limited.
> +
> /* Configure SW DCB default with ETS non-willing */
> ret = ice_dcb_sw_dflt_cfg(pf, false, true);
> if (ret) {
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH] net: Optimize flush calculation in inet_gro_receive()
From: David Laight @ 2026-04-14 9:36 UTC (permalink / raw)
To: Helge Deller
Cc: Kuniyuki Iwashima, deller, davem, dsahern, linux-kernel,
linux-parisc, netdev, edumazet
In-Reply-To: <49c05cd8-5ad0-4015-8f55-fed3416784bf@gmx.de>
On Tue, 14 Apr 2026 09:46:55 +0200
Helge Deller <deller@gmx.de> wrote:
> Hi Kikuyu and David,
...
> >>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> >>> index c7731e300a44..58cad2687c2c 100644
> >>> --- a/net/ipv4/af_inet.c
> >>> +++ b/net/ipv4/af_inet.c
> >>> @@ -1479,7 +1479,7 @@ struct sk_buff *inet_gro_receive(struct list_head *head, struct sk_buff *skb)
> >>> struct sk_buff *p;
> >>> unsigned int hlen;
> >>> unsigned int off;
> >>> - int flush = 1;
> >>> + u16 flush = 1;
> >>> int proto;
> >>>
> >>> off = skb_gro_offset(skb);
> >>> @@ -1504,7 +1504,8 @@ struct sk_buff *inet_gro_receive(struct list_head *head, struct sk_buff *skb)
> >>> goto out;
> >>>
> >>> NAPI_GRO_CB(skb)->proto = proto;
> >>> - flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (ntohl(*(__be32 *)&iph->id) & ~IP_DF));
> >>> + flush = (get_unaligned_be16(&iph->tot_len) ^ skb_gro_len(skb)) |
> >>> + (get_unaligned_be16(&iph->frag_off) & ~IP_DF);
> >>
> >> I think here we intentionally use 32-bit loads:
> >>
> >> commit
> >> Author: Herbert Xu <herbert@gondor.apana.org.au>
> >> Date: Tue May 26 18:50:29 2009
> >>
> >> ipv4: Use 32-bit loads for ID and length in GRO
>
> I see, this patch is exactly the opposite of mine.
>
> >> Before your patch, 32-bit load + bswap are used while
> >> 16-bit load + rol 8 after the change.
> >>
> >> I feel the 4-byte aligned load + bswap is faster than
> >> misaligned access + 8 times shift (Is this internally
> >> optimised like xchg for a single word size ?)
> >>
> >> Do you have some numbers ?
>
> No, I don't have.
> In the end it's very platform specific anyway.
>
> > Check on some architecture that doesn't support misaligned loads.
> > Actually, aren't the accesses aligned??
>
> The reason why I touched this code at all, is because I got unaligned
> accesses in that function on parisc.
> But those unaligned accesses were triggered by parisc-specific
> inline assembly, and not by this code here.
The network stack is supposed to ensure that all receive packets are
aligned to that IP header is on a 4-byte boundary.
This typically requires the ethernet receive buffer be 4n+2 aligned.
Unfortunately there is some ethernet hardware that requires 4n aligned
buffers (often on SoC devices with cpu that fault misaligned accesses).
(Just writing two bytes of garbage before the frame solves the issue.)
> So, I believe those accesses here are aligned, and the get_unaligned_XX()
> helpers make the code more readable, but are NOT necessary.
>
> That said, I suggest to drop my patch.
> It makes the code more readable, but probably will not improve speed.
I think the purpose of the change was to use the hardware's 32bit
byte-swapping memory loads rather than software swapping of the
16-bit items.
That shaves off a few instructions - and they can be measurable
in some of the network paths with specific workloads.
Remember, save 0.1% 100 times and the code runs 10% faster.
Every little bit can make a difference.
David
>
> Thanks for your help!
> Helge
>
> > Also on ones without 32bit byteswap (some do have byteswapping
> > memory reads).
> >
> > Also you may not want to change 'flush' to u16.
> > On non-x86 it may force the compiler add extra masking instructions.
> >
> > David
> >
> >>
> >>
> >> Before:
> >> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb))
> >> mov edx,DWORD PTR [rcx]
> >> bswap edx
> >> return skb->len - NAPI_GRO_CB(skb)->data_offset;
> >> mov r8d,DWORD PTR [rsi+0x38]
> >> mov r9d,DWORD PTR [rsi+0x70]
> >> sub r9d,r8d
> >> xor r9d,edx
> >> | (ntohl(*(__be32 *)&iph->id) & ~IP_DF));
> >> mov ebp,0xffbfffff
> >> and ebp,DWORD PTR [rcx+0x4]
> >> bswap ebp
> >> or ebp,r9d
> >>
> >>
> >> After:
> >> flush = (get_unaligned_be16(&iph->tot_len) ^ skb_gro_len(skb))
> >> movzx edx,WORD PTR [rcx+0x2]
> >> rol dx,0x8
> >> return skb->len - NAPI_GRO_CB(skb)->data_offset;
> >> mov r8d,DWORD PTR [rsi+0x38]
> >> mov r9d,DWORD PTR [rsi+0x70]
> >> sub r9d,r8d
> >> xor r9d,edx
> >> | (get_unaligned_be16(&iph->frag_off) & ~IP_DF);
> >> movzx ebp,WORD PTR [rcx+0x6]
> >> and ebp,0xffffffbf
> >> rol bp,0x8
> >> or ebp,r9d
> >>
> >
>
^ permalink raw reply
* Re: [PATCH iwl-next 8/10] ice: move ice_phy_get_speed_eth56g() from ice_ptp_hw.c to ice_common.c
From: Simon Horman @ 2026-04-14 9:38 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260410074921.1254213-9-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:19AM +0200, Aleksandr Loktionov wrote:
> ice_phy_get_speed_eth56g() is currently a file-local (static)
> helper in ice_ptp_hw.c. Future users outside that compilation
> unit require access to it.
FWIIW, I think it would be slightly better if this patch was accompanied by
such a user.
>
> Move the function to ice_common.c, add a declaration in
> ice_common.h, and relocate the enum ice_eth56g_link_spd from
> ice_ptp_hw.h to ice_type.h so it is visible to callers of the
> new exported function.
>
> Suggested-by: Karol Kolacinski <karol.kolacinski@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH iwl-next 9/10] ice: use inline helpers instead of memcmp() for IPv6 mask checks in ice_ethtool_fdir
From: Simon Horman @ 2026-04-14 9:39 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Larysa Zaremba
In-Reply-To: <20260410074921.1254213-10-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:20AM +0200, Aleksandr Loktionov wrote:
> Replace static full_ipv6_addr_mask / zero_ipv6_addr_mask structs
> and the associated memcmp() calls in ice_ethtool_fdir.c with the
> kernel-provided ipv6_addr_any() helper and a new ice_ipv6_mask_full()
> inline, reducing boilerplate and making intent clearer.
>
> Suggested-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH iwl-next 10/10] ice: promote Tx FIFO drain timeout message from dev_dbg to dev_warn
From: Simon Horman @ 2026-04-14 9:39 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Jacob Keller
In-Reply-To: <20260410074921.1254213-11-aleksandr.loktionov@intel.com>
On Fri, Apr 10, 2026 at 09:49:21AM +0200, Aleksandr Loktionov wrote:
> The message emitted when the Tx FIFO fails to drain within the
> timeout period is currently at dev_dbg level, making it invisible
> unless debug logging is enabled. Promote it to dev_warn so that
> users and administrators can detect Tx timestamp path issues
> without enabling extra logging.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH] net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler
From: Paolo Abeni @ 2026-04-14 9:41 UTC (permalink / raw)
To: Pavitra Jha, w; +Cc: chandrashekar.devegowda, linux-wwan, netdev, stable
In-Reply-To: <20260411083957.567676-1-jhapavitra98@gmail.com>
On 4/11/26 10:39 AM, Pavitra Jha wrote:
> t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as
> a loop bound over port_msg->data[] without checking that the message buffer
> contains sufficient data. A modem sending port_count=65535 in a 12-byte
> buffer triggers a slab-out-of-bounds read of up to 262140 bytes.
>
> Add a struct_size() check after extracting port_count and before the loop.
> Pass msg_len from both call sites: skb->len at the DPMAIF path after
> skb_pull(), and the captured rt_feature->data_len at the handshake path.
>
> Fixes: 1e3e8eb9b6e3 ("net: wwan: t7xx: Add control DMA interface")
Wrong fixes tag:
fatal: ambiguous argument '1e3e8eb9b6e3': unknown revision or path not
in the working tree.
> diff --git a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> index ae632ef96..d984a688d 100644
> --- a/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> +++ b/drivers/net/wwan/t7xx/t7xx_port_ctrl_msg.c
> @@ -124,7 +124,7 @@ static int fsm_ee_message_handler(struct t7xx_port *port, struct t7xx_fsm_ctl *c
> * * 0 - Success.
> * * -EFAULT - Message check failure.
> */
> -int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg)
> +int t7xx_port_enum_msg_handler(struct t7xx_modem *md, void *msg, size_t msg_len)
Undocumented new argument
/P
^ permalink raw reply
* Re: [PATCH net] net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
From: Paolo Abeni @ 2026-04-14 9:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb, netdev
Cc: linux-kernel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, stable
In-Reply-To: <2026041134-dreamboat-buddhism-d1ec@gregkh>
On 4/11/26 1:01 PM, Greg Kroah-Hartman wrote:
> A malicious USB device claiming to be a CDC Phonet modem can overflow
> the skb_shared_info->frags[] array by sending an unbounded sequence of
> full-page bulk transfers.
>
> Drop the skb and increment the length error when the frag limit is
> reached. This matches the same fix that commit f0813bcd2d9d ("net:
> wwan: t7xx: fix potential skb->frags overflow in RX path") did for the
> t7xx driver.
>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: stable <stable@kernel.org>
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It looks like the fixes tag should be:
Fixes: 87cf65601e17 ("USB host CDC Phonet network interface driver")
Right?
/P
^ permalink raw reply
* Re: [PATCH] net: Optimize flush calculation in inet_gro_receive()
From: Eric Dumazet @ 2026-04-14 9:57 UTC (permalink / raw)
To: David Laight
Cc: Helge Deller, Kuniyuki Iwashima, deller, davem, dsahern,
linux-kernel, linux-parisc, netdev
In-Reply-To: <20260414103633.4d5fe92a@pumpkin>
On Tue, Apr 14, 2026 at 2:36 AM David Laight
<david.laight.linux@gmail.com> wrote:
> The network stack is supposed to ensure that all receive packets are
> aligned to that IP header is on a 4-byte boundary.
> This typically requires the ethernet receive buffer be 4n+2 aligned.
> Unfortunately there is some ethernet hardware that requires 4n aligned
> buffers (often on SoC devices with cpu that fault misaligned accesses).
> (Just writing two bytes of garbage before the frame solves the issue.)
This is mostly true, but depends on NET_IP_ALIGN,
On x86, this constant was changed to 0 back in 2010.
commit ea812ca1b06113597adcd8e70c0f84a413d97544
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue Jun 29 18:38:00 2010 +0000
x86: Align skb w/ start of cacheline on newer core 2/Xeon Arch
^ permalink raw reply
* Re: [PATCH net] net: sched: em_text: require NUL-terminated algo name
From: Paolo Abeni @ 2026-04-14 10:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, netdev
Cc: linux-kernel, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Simon Horman, stable
In-Reply-To: <2026041150-task-path-81dd@gregkh>
On 4/11/26 1:10 PM, Greg Kroah-Hartman wrote:
> em_text_change() copies the user-supplied tcf_em_text struct from
> netlink and passes conf->algo straight to textsearch_prepare(), which
> forwards it to lookup_ts_algo() (strcmp) and request_module() (vsnprintf
> %s). But the algo[16] field is never validated to be NULL-terminated,
> so a fully populated array reads past it into the adjacent
> from_offset/to_offset/pattern_len fields and the trailing pattern bytes
> during the string operations.
>
> This type of pattern is properly checked in the string_mt_check() for
> xt_string netfilter matching function, but for some reason was not added
> here, so fix this up by doing the same exact thing.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: Jiri Pirko <jiri@resnulli.us>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Simon Horman <horms@kernel.org>
> Fixes: d675c989ed2d ("[PKT_SCHED]: Packet classification based on textsearch (ematch)")
> Cc: stable <stable@kernel.org>
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> Note, my tools flagged this, so I fixed this up the same way that
> string_mt_check() did, but if there is some other way that this should
> be resolved, or I got this totally wrong that this isn't an issue,
> please let me know, thanks!
>
>
> net/sched/em_text.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/sched/em_text.c b/net/sched/em_text.c
> index 343f1aebeec2..24a8aa21971d 100644
> --- a/net/sched/em_text.c
> +++ b/net/sched/em_text.c
> @@ -58,6 +58,9 @@ static int em_text_change(struct net *net, void *data, int len,
> if (len < sizeof(*conf) || len < (sizeof(*conf) + conf->pattern_len))
> return -EINVAL;
>
> + if (conf->algo[sizeof(conf->algo) - 1] != '\0')
> + return -EINVAL;
The addressed issue looks real to me, but sashiko found a problem with
this fix:
---
Is this NUL-termination check too strict and could it introduce an ABI
regression?
If a userspace application sends a valid, NUL-terminated string that is
shorter than 15 characters, but does not explicitly zero-pad the
remaining uninitialized bytes in the tcf_em_text struct, this check will
fail with -EINVAL.
Prior to this patch, the kernel's string operations safely stopped
reading at the first \0 byte, correctly processing these shorter
strings. Rejecting previously valid structures breaks backward
compatibility with existing userspace binaries.
Would it be better to check for NUL-termination using memchr() or
strnlen() instead? For example, memchr(conf->algo, '\0',
sizeof(conf->algo)) == NULL.
---
/P
^ permalink raw reply
* Re: [net,PATCH v2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Marek Vasut @ 2026-04-14 10:07 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Jakub Kicinski
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Nicolai Buchwitz, Paolo Abeni, Ronald Wahl, Yicong Hui,
linux-kernel, Thomas Gleixner
In-Reply-To: <20260413161000.P_SLxmZl@linutronix.de>
On 4/13/26 6:10 PM, Sebastian Andrzej Siewior wrote:
>> TBH changing the driver feels like a workaround / invitation for a
>> whack-a-mole game. I'd prefer to fix the skb allocation.
>
> The problem is that _irq() implicitly disables bh processing but this
> does not happen. Forcing this is possible but expensive.
> However, I did remove lock from bh_disable() on RT.
>
> Marek: from which kernel version was this backtrace?
That was v6.12.79-rt17-rebase where it was easy to trigger , here is a
fresh one from next-20260413 with b44596ffe1b4 ("ARM: Allow to enable
RT") from stable-rt added on top:
"
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P127/5:b..l
rcu: (detected by 1, t=2102 jiffies, g=-503, q=1 ncpus=2)
task:irq/68-eth1 state:D stack:0 pid:127 tgid:127 ppid:2
task_flags:0x4208040 flags:0x00000000
Call trace:
__schedule from schedule_rtlock+0x1c/0x34
schedule_rtlock from rtlock_slowlock_locked+0x548/0x904
rtlock_slowlock_locked from rt_spin_lock+0x60/0x9c
rt_spin_lock from ks8851_start_xmit_par+0x74/0x1a8
ks8851_start_xmit_par from netdev_start_xmit+0x20/0x44
netdev_start_xmit from dev_hard_start_xmit+0xd0/0x188
dev_hard_start_xmit from sch_direct_xmit+0xb8/0x25c
sch_direct_xmit from __qdisc_run+0x1f8/0x4ec
__qdisc_run from qdisc_run+0x1c/0x28
qdisc_run from net_tx_action+0x1f0/0x268
net_tx_action from handle_softirqs+0x1a4/0x270
handle_softirqs from __local_bh_enable_ip+0xcc/0xe0
__local_bh_enable_ip from __alloc_skb+0xd8/0x128
__alloc_skb from __netdev_alloc_skb+0x3c/0x19c
__netdev_alloc_skb from ks8851_irq+0x388/0x4d4
ks8851_irq from irq_thread_fn+0x24/0x64
irq_thread_fn from irq_thread+0x178/0x28c
irq_thread from kthread+0x12c/0x138
kthread from ret_from_fork+0x14/0x28
Exception stack(0xf4c99fb0 to 0xf4c99ff8)
9fa0: 00000000 00000000 00000000
00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
"
^ permalink raw reply
* Re: [PATCH net] net: ethernet: ravb: Do not check URAM suspension when WoL is active
From: Geert Uytterhoeven @ 2026-04-14 10:20 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Paul Barker, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Yoshihiro Shimoda, netdev,
linux-renesas-soc
In-Reply-To: <20260412173213.3179426-1-niklas.soderlund+renesas@ragnatech.se>
On Sun, 12 Apr 2026 at 19:33, Niklas Söderlund
<niklas.soderlund+renesas@ragnatech.se> wrote:
> When updating the driver to match latest datasheet to suspend access to
> URAM when suspending DMA transfers a corner-case was missed, URAM access
> will not be suspended if WoL is enabled. This lead to the error message
> (correctly) being triggered as URAM access is not suspended even tho
> it's requested as part of stopping DMA.
>
> Avoid checking if URAM access is suspended and printing the error
> message if WoL is enabled when we suspend the system, as we know it will
> not be.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Closes: https://lore.kernel.org/all/CAMuHMdWnjV%3DHGE1o08zLhUfTgOSene5fYx1J5GG10mB%2BToq8qg@mail.gmail.com/
> Fixes: 353d8e7989b6 ("net: ethernet: ravb: Suspend and resume the transmission flow")
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net] net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
From: patchwork-bot+netdevbpf @ 2026-04-14 10:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-usb, netdev, linux-kernel, andrew+netdev, davem, edumazet,
kuba, pabeni, stable
In-Reply-To: <2026041134-dreamboat-buddhism-d1ec@gregkh>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Sat, 11 Apr 2026 13:01:35 +0200 you wrote:
> A malicious USB device claiming to be a CDC Phonet modem can overflow
> the skb_shared_info->frags[] array by sending an unbounded sequence of
> full-page bulk transfers.
>
> Drop the skb and increment the length error when the frag limit is
> reached. This matches the same fix that commit f0813bcd2d9d ("net:
> wwan: t7xx: fix potential skb->frags overflow in RX path") did for the
> t7xx driver.
>
> [...]
Here is the summary with links:
- [net] net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete()
https://git.kernel.org/netdev/net/c/600dc40554dc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] nfc: s3fwrn5: switch to GPIO descriptor API
From: deep @ 2026-04-14 10:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Linus Walleij, Bartosz Golaszewski, netdev, linux-nfc,
linux-kernel, linux-gpio, Kenet Jovan Sokoli
From: Kenet Jovan Sokoli <deep@crimson.net.eu.org>
I am working on cleaning up some legacy GPIO usage in the NFC subsystem.
This patch converts the s3fwrn5 driver to use the modern descriptor based
GPIO API instead of the old integer based one.
Specifically:
- I changed the gpio_en and gpio_fw_wake types to struct gpio_desc.
- Replaced the manual DT parsing with devm_gpiod_get() in the probe
functions.
- Updated the calls in phy_common.c to use gpiod_set_value().
This also allowed me to remove the s3fwrn5_i2c_parse_dt and
s3fwrn82_uart_parse_dt functions as they are no longer needed with the
new API.
Signed-off-by: Kenet Jovan Sokoli <deep@crimson.net.eu.org>
---
I have verified that this patch builds successfully with "make M=drivers/nfc/s3fwrn5"
"scripts/checkpatch.pl" with no errors or warnings.
This is very complicated stuff, but I am learning a lot by doing these cleanup works.
I really hope I can contribute as much as possible to this environment, little by little.
---
drivers/nfc/s3fwrn5/i2c.c | 58 ++++++--------------------------
drivers/nfc/s3fwrn5/phy_common.c | 12 +++----
drivers/nfc/s3fwrn5/phy_common.h | 5 +--
drivers/nfc/s3fwrn5/uart.c | 43 ++++++-----------------
4 files changed, 31 insertions(+), 87 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/i2c.c b/drivers/nfc/s3fwrn5/i2c.c
index 110d086cfe5b..a629fbcd3237 100644
--- a/drivers/nfc/s3fwrn5/i2c.c
+++ b/drivers/nfc/s3fwrn5/i2c.c
@@ -8,9 +8,8 @@
#include <linux/clk.h>
#include <linux/i2c.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/delay.h>
-#include <linux/of_gpio.h>
#include <linux/of_irq.h>
#include <linux/module.h>
@@ -146,37 +145,6 @@ static irqreturn_t s3fwrn5_i2c_irq_thread_fn(int irq, void *phy_id)
return IRQ_HANDLED;
}
-static int s3fwrn5_i2c_parse_dt(struct i2c_client *client)
-{
- struct s3fwrn5_i2c_phy *phy = i2c_get_clientdata(client);
- struct device_node *np = client->dev.of_node;
-
- if (!np)
- return -ENODEV;
-
- phy->common.gpio_en = of_get_named_gpio(np, "en-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_en)) {
- /* Support also deprecated property */
- phy->common.gpio_en = of_get_named_gpio(np,
- "s3fwrn5,en-gpios",
- 0);
- if (!gpio_is_valid(phy->common.gpio_en))
- return -ENODEV;
- }
-
- phy->common.gpio_fw_wake = of_get_named_gpio(np, "wake-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_fw_wake)) {
- /* Support also deprecated property */
- phy->common.gpio_fw_wake = of_get_named_gpio(np,
- "s3fwrn5,fw-gpios",
- 0);
- if (!gpio_is_valid(phy->common.gpio_fw_wake))
- return -ENODEV;
- }
-
- return 0;
-}
-
static int s3fwrn5_i2c_probe(struct i2c_client *client)
{
struct s3fwrn5_i2c_phy *phy;
@@ -193,21 +161,17 @@ static int s3fwrn5_i2c_probe(struct i2c_client *client)
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
- ret = s3fwrn5_i2c_parse_dt(client);
- if (ret < 0)
- return ret;
-
- ret = devm_gpio_request_one(&phy->i2c_dev->dev, phy->common.gpio_en,
- GPIOF_OUT_INIT_HIGH, "s3fwrn5_en");
- if (ret < 0)
- return ret;
-
- ret = devm_gpio_request_one(&phy->i2c_dev->dev,
- phy->common.gpio_fw_wake,
- GPIOF_OUT_INIT_LOW, "s3fwrn5_fw_wake");
- if (ret < 0)
- return ret;
+ phy->common.gpio_en = devm_gpiod_get(&client->dev, "en", GPIOD_OUT_HIGH);
+ if (IS_ERR(phy->common.gpio_en)) {
+ return dev_err_probe(&client->dev, PTR_ERR(phy->common.gpio_en),
+ "Failed to get EN gpio\n");
+ }
+ phy->common.gpio_fw_wake = devm_gpiod_get(&client->dev, "wake", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->common.gpio_fw_wake)) {
+ return dev_err_probe(&client->dev, PTR_ERR(phy->common.gpio_fw_wake),
+ "Failed to get WAKE gpio\n");
+ }
/*
* S3FWRN5 depends on a clock input ("XI" pin) to function properly.
* Depending on the hardware configuration this could be an always-on
diff --git a/drivers/nfc/s3fwrn5/phy_common.c b/drivers/nfc/s3fwrn5/phy_common.c
index deb2c039f0fd..e802b4e609c8 100644
--- a/drivers/nfc/s3fwrn5/phy_common.c
+++ b/drivers/nfc/s3fwrn5/phy_common.c
@@ -8,7 +8,7 @@
* Bongsu Jeon <bongsu.jeon@samsung.com>
*/
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/delay.h>
#include <linux/module.h>
@@ -19,7 +19,7 @@ void s3fwrn5_phy_set_wake(void *phy_id, bool wake)
struct phy_common *phy = phy_id;
mutex_lock(&phy->mutex);
- gpio_set_value(phy->gpio_fw_wake, wake);
+ gpiod_set_value(phy->gpio_fw_wake, wake);
if (wake)
msleep(S3FWRN5_EN_WAIT_TIME);
mutex_unlock(&phy->mutex);
@@ -33,14 +33,14 @@ bool s3fwrn5_phy_power_ctrl(struct phy_common *phy, enum s3fwrn5_mode mode)
phy->mode = mode;
- gpio_set_value(phy->gpio_en, 1);
- gpio_set_value(phy->gpio_fw_wake, 0);
+ gpiod_set_value(phy->gpio_en, 1);
+ gpiod_set_value(phy->gpio_fw_wake, 0);
if (mode == S3FWRN5_MODE_FW)
- gpio_set_value(phy->gpio_fw_wake, 1);
+ gpiod_set_value(phy->gpio_fw_wake, 1);
if (mode != S3FWRN5_MODE_COLD) {
msleep(S3FWRN5_EN_WAIT_TIME);
- gpio_set_value(phy->gpio_en, 0);
+ gpiod_set_value(phy->gpio_en, 0);
msleep(S3FWRN5_EN_WAIT_TIME);
}
diff --git a/drivers/nfc/s3fwrn5/phy_common.h b/drivers/nfc/s3fwrn5/phy_common.h
index 9cef25436bf9..10210a8fd755 100644
--- a/drivers/nfc/s3fwrn5/phy_common.h
+++ b/drivers/nfc/s3fwrn5/phy_common.h
@@ -13,6 +13,7 @@
#include <linux/mutex.h>
#include <net/nfc/nci_core.h>
+#include <linux/gpio/consumer.h>
#include "s3fwrn5.h"
@@ -21,8 +22,8 @@
struct phy_common {
struct nci_dev *ndev;
- int gpio_en;
- int gpio_fw_wake;
+ struct gpio_desc *gpio_en;
+ struct gpio_desc *gpio_fw_wake;
struct mutex mutex;
diff --git a/drivers/nfc/s3fwrn5/uart.c b/drivers/nfc/s3fwrn5/uart.c
index 4ee481bd7e96..5a7c7741a881 100644
--- a/drivers/nfc/s3fwrn5/uart.c
+++ b/drivers/nfc/s3fwrn5/uart.c
@@ -15,8 +15,7 @@
#include <linux/netdevice.h>
#include <linux/of.h>
#include <linux/serdev.h>
-#include <linux/gpio.h>
-#include <linux/of_gpio.h>
+#include <linux/gpio/consumer.h>
#include "phy_common.h"
@@ -92,25 +91,6 @@ static const struct of_device_id s3fwrn82_uart_of_match[] = {
};
MODULE_DEVICE_TABLE(of, s3fwrn82_uart_of_match);
-static int s3fwrn82_uart_parse_dt(struct serdev_device *serdev)
-{
- struct s3fwrn82_uart_phy *phy = serdev_device_get_drvdata(serdev);
- struct device_node *np = serdev->dev.of_node;
-
- if (!np)
- return -ENODEV;
-
- phy->common.gpio_en = of_get_named_gpio(np, "en-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_en))
- return -ENODEV;
-
- phy->common.gpio_fw_wake = of_get_named_gpio(np, "wake-gpios", 0);
- if (!gpio_is_valid(phy->common.gpio_fw_wake))
- return -ENODEV;
-
- return 0;
-}
-
static int s3fwrn82_uart_probe(struct serdev_device *serdev)
{
struct s3fwrn82_uart_phy *phy;
@@ -144,20 +124,19 @@ static int s3fwrn82_uart_probe(struct serdev_device *serdev)
serdev_device_set_flow_control(serdev, false);
- ret = s3fwrn82_uart_parse_dt(serdev);
- if (ret < 0)
- goto err_serdev;
-
- ret = devm_gpio_request_one(&phy->ser_dev->dev, phy->common.gpio_en,
- GPIOF_OUT_INIT_HIGH, "s3fwrn82_en");
- if (ret < 0)
+ phy->common.gpio_en = devm_gpiod_get(&serdev->dev, "en", GPIOD_OUT_HIGH);
+ if (IS_ERR(phy->common.gpio_en)) {
+ ret = dev_err_probe(&serdev->dev, PTR_ERR(phy->common.gpio_en),
+ "failed to get en gpio\n");
goto err_serdev;
+ }
- ret = devm_gpio_request_one(&phy->ser_dev->dev,
- phy->common.gpio_fw_wake,
- GPIOF_OUT_INIT_LOW, "s3fwrn82_fw_wake");
- if (ret < 0)
+ phy->common.gpio_fw_wake = devm_gpiod_get(&serdev->dev, "wake", GPIOD_OUT_LOW);
+ if (IS_ERR(phy->common.gpio_fw_wake)) {
+ ret = dev_err_probe(&serdev->dev, PTR_ERR(phy->common.gpio_fw_wake),
+ "failed to get wake gpio\n");
goto err_serdev;
+ }
ret = s3fwrn5_probe(&phy->common.ndev, phy, &phy->ser_dev->dev,
&uart_phy_ops);
--
2.43.0
^ permalink raw reply related
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