Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next v1] r8169: implement get_module functions for rtl8127atf
From: Fabio Baltieri @ 2026-04-04 22:37 UTC (permalink / raw)
  To: Heiner Kallweit
  Cc: nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Russell King - ARM Linux,
	Andrew Lunn, netdev, linux-kernel
In-Reply-To: <4f8310c2-07be-452a-84fa-0ec87d985651@gmail.com>

On Sat, Apr 04, 2026 at 11:55:25PM +0200, Heiner Kallweit wrote:
> On 04.04.2026 22:13, Fabio Baltieri wrote:
> > Implement get_module_info and get_module_eeprom for supported devices,
> > right now that's the rtl8127atf.
> > 
> > This enables using ethtool to retrieve the transceiver identification
> > and diagnostic data.
> > 
> > Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
> > ---
> > 
> > Hi,
> > 
> > Realtek released a new out of tree driver for the rtl8127 and it
> > includes some code that exposes the I2C controller connected to the SFP
> > port.
> > 
> > This patch implements get_module_info and get_module_eeprom based on the
> > information found on that driver, it allows ethtool to fetch the SFP
> > module information, which is useful both to identify the module and to
> > track the health of fiber optic transceivers.
> > 
> > The logic for the SFF standard and i2c address selection is borrowed
> > directly from the aquantia/atlantic driver, I don't have a lot of stuff
> > to test it but I was able to trigger all code paths from a fiber optic
> > transceiver and an SFP cable I have available.
> > 
> 
> Hi Fabio, thanks for the patch. Being able to access the SFP I2C bus is an
> important step towards future phylink/SFP support.
> 
> @Russell/@Andrew
> I'm not really familiar with the phylink and sfp code. And I would like to have
> the functionality being implemented here reusable once we do further steps
> towards phylink support in r8169. So how shall the code be modeled, which
> components are needed?
> - Shall the SFP I2C bus be modeled as a struct i2c_adapter?
> - Shall we (partially?) implement a struct sfp, so that functions like
>   sfp_module_eeprom() can be used (implicitly)?

Yeah happy to hear any input on it, the controller actually seems to be
a designware IP and there is some reusable code for it but what I've
seen done for other drivers for this functionality is to implement a
minimum i2c "read bulk" functionality in the driver itself, so that's
what I proposed here too, the code is fairly simple after all. However I
did borrow some logic much verbatim from the atlantis driver as I
mentioned, happy to hear if there's a path to reuse.

> 
> I assume this patch includes logic which duplicates what is available in
> phylink/sfp already. I'd a appreciate any hints you can provide.
> 
> Thanks, Heiner

^ permalink raw reply

* [PATCH net] tg3: Add PowerEdge R740xd to AER quirk list
From: Oskar Ray-Frayssinet @ 2026-04-04 22:28 UTC (permalink / raw)
  To: pavan.chebbi
  Cc: mchan, andrew+netdev, davem, edumazet, kuba, pabeni, horms,
	lszubowi, netdev, linux-kernel, Oskar Ray-Frayssinet

The PowerEdge R740xd is a variant of the R740 that also triggers
a fatal PCIe AER event during system reboot. Add it to the DMI
list to apply the same workaround.

Fixes: e0efe83ed325 ("tg3: Disable tg3 PCIe AER on system reboot")

Signed-off-by: Oskar Ray-Frayssinet <rayfraytech@gmail.com>
---
 drivers/net/ethernet/broadcom/tg3.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 73a4b569b03e..ae06ed4f0ed7 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -18216,6 +18216,12 @@ static const struct dmi_system_id tg3_restart_aer_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R740"),
 		},
 	},
+	{
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R740xd"),
+		},
+	},
 	{
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-- 
2.43.0


^ permalink raw reply related

* [PATCH net-next] bonding: remove unused bond_is_first_slave and bond_is_last_slave macros
From: Xiang Mei @ 2026-04-04 22:04 UTC (permalink / raw)
  To: netdev; +Cc: jv, andy, davem, edumazet, kuba, pabeni, Xiang Mei

Since commit 2884bf72fb8f ("net: bonding: fix use-after-free in
bond_xmit_broadcast()"), bond_is_last_slave() was only used in
bond_xmit_broadcast().  After the recent fix replaced that usage with
a simple index comparison, bond_is_last_slave() has no remaining
callers.  bond_is_first_slave() likewise has no callers.

Remove both unused macros.

Signed-off-by: Xiang Mei <xmei5@asu.edu>
---
 include/net/bonding.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/net/bonding.h b/include/net/bonding.h
index 395c6e281c5fc..a95ec27c1c1a8 100644
--- a/include/net/bonding.h
+++ b/include/net/bonding.h
@@ -69,9 +69,6 @@
 #define bond_first_slave_rcu(bond) \
 	netdev_lower_get_first_private_rcu(bond->dev)
 
-#define bond_is_first_slave(bond, pos) (pos == bond_first_slave(bond))
-#define bond_is_last_slave(bond, pos) (pos == bond_last_slave(bond))
-
 /**
  * bond_for_each_slave - iterate over all slaves
  * @bond:	the bond holding this list
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH net-next v1] r8169: implement get_module functions for rtl8127atf
From: Heiner Kallweit @ 2026-04-04 21:55 UTC (permalink / raw)
  To: Fabio Baltieri, nic_swsd, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Russell King - ARM Linux, Andrew Lunn
  Cc: netdev, linux-kernel
In-Reply-To: <20260404201333.2849-1-fabio.baltieri@gmail.com>

On 04.04.2026 22:13, Fabio Baltieri wrote:
> Implement get_module_info and get_module_eeprom for supported devices,
> right now that's the rtl8127atf.
> 
> This enables using ethtool to retrieve the transceiver identification
> and diagnostic data.
> 
> Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
> ---
> 
> Hi,
> 
> Realtek released a new out of tree driver for the rtl8127 and it
> includes some code that exposes the I2C controller connected to the SFP
> port.
> 
> This patch implements get_module_info and get_module_eeprom based on the
> information found on that driver, it allows ethtool to fetch the SFP
> module information, which is useful both to identify the module and to
> track the health of fiber optic transceivers.
> 
> The logic for the SFF standard and i2c address selection is borrowed
> directly from the aquantia/atlantic driver, I don't have a lot of stuff
> to test it but I was able to trigger all code paths from a fiber optic
> transceiver and an SFP cable I have available.
> 

Hi Fabio, thanks for the patch. Being able to access the SFP I2C bus is an
important step towards future phylink/SFP support.

@Russell/@Andrew
I'm not really familiar with the phylink and sfp code. And I would like to have
the functionality being implemented here reusable once we do further steps
towards phylink support in r8169. So how shall the code be modeled, which
components are needed?
- Shall the SFP I2C bus be modeled as a struct i2c_adapter?
- Shall we (partially?) implement a struct sfp, so that functions like
  sfp_module_eeprom() can be used (implicitly)?

I assume this patch includes logic which duplicates what is available in
phylink/sfp already. I'd a appreciate any hints you can provide.

Thanks, Heiner

> Demo:
> 
> # Fiber transceiver
> $ sudo ethtool -m eth1
>         Identifier                                : 0x03 (SFP)
>         Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
>         Connector                                 : 0x07 (LC)
>         Transceiver codes                         : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>         Transceiver type                          : 10G Ethernet: 10G Base-SR
>         Encoding                                  : 0x06 (64B/66B)
>         BR Nominal                                : 10300MBd
>         Rate identifier                           : 0x00 (unspecified)
>         Length (SMF)                              : 0km
>         Length (OM2)                              : 80m
>         Length (OM1)                              : 30m
>         Length (Copper or Active cable)           : 0m
>         Length (OM3)                              : 300m
>         Laser wavelength                          : 850nm
>         Vendor name                               : QSFPTEK
>         Vendor OUI                                : 00:0a:0d
>         Vendor PN                                 : QT-SFP+-SR
>         Vendor rev                                : 
>         Option values                             : 0x00 0x1a
>         Option                                    : TX_DISABLE implemented
>         BR margin max                             : 10%
>         BR margin min                             : 88%
>         Vendor SN                                 : QT8250805131
>         Date code                                 : 250806
>         Optical diagnostics support               : Yes
>         Laser bias current                        : 5.880 mA
>         Laser output power                        : 0.5431 mW / -2.65 dBm
>         Receiver signal average optical power     : 0.6912 mW / -1.60 dBm
>         Module temperature                        : 20.70 degrees C / 69.25 degrees F
>         Module voltage                            : 3.3000 V
> ...
> 
> # DAC
> $ sudo ethtool -m eth1
>         Identifier                                : 0x03 (SFP)
>         Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
>         Connector                                 : 0x21 (Copper pigtail)
>         Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x00
>         Transceiver type                          : Passive Cable
>         Encoding                                  : 0x00 (unspecified)
>         BR Nominal                                : 10300MBd
>         Rate identifier                           : 0x00 (unspecified)
>         Length (SMF)                              : 0km
>         Length (OM2)                              : 0m
>         Length (OM1)                              : 0m
>         Length (Copper or Active cable)           : 1m
>         Length (OM3)                              : 0m
>         Passive Cu cmplnce.                       : 0x01 (SFF-8431 appendix E [SFF-8472 rev10.4 only])
>         Vendor name                               : OEM
>         Vendor OUI                                : 00:40:20
>         Vendor PN                                 : SFP-H10GB-CU1M
>         Vendor rev                                : R
>         Option values                             : 0x00 0x00
>         BR margin max                             : 0%
>         BR margin min                             : 0%
>         Vendor SN                                 : CSC240415030053
>         Date code                                 : 240508
> ...
> 
> # No module
> $ sudo ethtool -m eth1
> netlink error: Input/output error
> 
> Cheers,
> Fabio
> 
> 
>  drivers/net/ethernet/realtek/r8169_main.c | 177 ++++++++++++++++++++++
>  1 file changed, 177 insertions(+)
> 
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 58788d196c57..45ec0b5c1c21 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -2411,6 +2411,181 @@ static int rtl8169_set_link_ksettings(struct net_device *ndev,
>  	return 0;
>  }
>  
> +#define R8127_SDS_I2C_CON		0xe200
> +#define R8127_SDS_I2C_TAR		0xe204
> +#define R8127_SDS_I2C_DATA_CMD		0xe210
> +#define R8127_SDS_I2C_FS_SCL_HCNT	0xe21c
> +#define R8127_SDS_I2C_FS_SCL_LCNT	0xe220
> +#define R8127_SDS_I2C_INTR_STAT		0xe22c
> +#define R8127_SDS_I2C_EN		0xe26c
> +#define R8127_SDS_I2C_STATUS		0xe270
> +
> +#define R8127_SDS_I2C_STATUS_ACTIVITY BIT(0)
> +#define R8127_SDS_I2C_RX_FIFO_NOT_EMPTY BIT(3)
> +#define R8127_SDS_I2C_STAT_TX_ABRT BIT(6)
> +
> +#define R8127_SDS_I2C_CMD_READ BIT(8)
> +#define R8127_SDS_I2C_CMD_STOP BIT(9)
> +#define R8127_SDS_I2C_CMD_RESTART BIT(10)
> +
> +#define SFF_8472_ID_ADDR 0x50
> +#define SFF_8472_DIAGNOSTICS_ADDR 0x51
> +
> +#define SFF_8472_COMP_ADDR      0x5e
> +#define SFF_8472_DOM_TYPE_ADDR  0x5c
> +
> +#define SFF_8472_ADDRESS_CHANGE_REQ_MASK 0x4
> +
> +static void r8127_sfp_sds_i2c_init(struct rtl8169_private *tp, u8 addr)
> +{
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_EN, 0);
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_CON, 0x65);
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_TAR, addr);
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_FS_SCL_HCNT, 0x23a);
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_FS_SCL_LCNT, 0x23a);
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_EN, 1);
> +}
> +
> +static void r8127_sfp_sds_i2c_disable(struct rtl8169_private *tp)
> +{
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_EN, 0);
> +}
> +
> +DECLARE_RTL_COND(r8127_sfp_sds_i2c_idle_cond)
> +{
> +	u16 val;
> +
> +	val = r8168_mac_ocp_read(tp, R8127_SDS_I2C_STATUS);
> +
> +	return val & R8127_SDS_I2C_STATUS_ACTIVITY;
> +}
> +
> +DECLARE_RTL_COND(r8127_sfp_sds_i2c_rx_fifo_cond)
> +{
> +	u16 val;
> +
> +	val = r8168_mac_ocp_read(tp, R8127_SDS_I2C_STATUS);
> +
> +	return val & R8127_SDS_I2C_RX_FIFO_NOT_EMPTY;
> +}
> +
> +static int r8127_sfp_sds_i2c_read(struct rtl8169_private *tp,
> +				  u8 addr, u8 off, u8 *buf, u16 len)
> +{
> +	u16 intr_stat;
> +	int ret = 0;
> +
> +	r8127_sfp_sds_i2c_init(tp, addr);
> +
> +	r8168_mac_ocp_write(tp, R8127_SDS_I2C_DATA_CMD, off);
> +
> +	if (!rtl_loop_wait_low(tp, &r8127_sfp_sds_i2c_idle_cond, 10, 100)) {
> +		ret = -EIO;
> +		goto out;
> +	}
> +
> +	intr_stat = r8168_mac_ocp_read(tp, R8127_SDS_I2C_INTR_STAT);
> +	if (intr_stat & R8127_SDS_I2C_STAT_TX_ABRT) {
> +		/* NACK */
> +		ret = -EIO;
> +		goto out;
> +	}
> +
> +	for (int i = 0; i < len; i++) {
> +		u16 data = R8127_SDS_I2C_CMD_READ;
> +
> +		if (i == len - 1)
> +			data |= R8127_SDS_I2C_CMD_STOP;
> +		if (i == 0)
> +			data |= R8127_SDS_I2C_CMD_RESTART;
> +
> +		r8168_mac_ocp_write(tp, R8127_SDS_I2C_DATA_CMD, data);
> +
> +		if (!rtl_loop_wait_high(tp, &r8127_sfp_sds_i2c_rx_fifo_cond,
> +					10, 1000)) {
> +			ret = -ETIMEDOUT;
> +			goto out;
> +		}
> +
> +		buf[i] = r8168_mac_ocp_read(tp, R8127_SDS_I2C_DATA_CMD);
> +	}
> +
> +out:
> +	r8127_sfp_sds_i2c_disable(tp);
> +
> +	return ret;
> +}
> +
> +static int rtl8169_get_module_info(struct net_device *ndev,
> +				   struct ethtool_modinfo *modinfo)
> +{
> +	struct rtl8169_private *tp = netdev_priv(ndev);
> +	u8 compliance_val, dom_type;
> +	int ret;
> +
> +	if (!tp->sfp_mode)
> +		return -EOPNOTSUPP;
> +
> +	ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_ID_ADDR,
> +				     SFF_8472_COMP_ADDR, &compliance_val, 1);
> +	if (ret)
> +		return ret;
> +
> +	ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_ID_ADDR,
> +				     SFF_8472_DOM_TYPE_ADDR, &dom_type, 1);
> +	if (ret)
> +		return ret;
> +
> +	if (dom_type & SFF_8472_ADDRESS_CHANGE_REQ_MASK || compliance_val == 0x00) {
> +		modinfo->type = ETH_MODULE_SFF_8079;
> +		modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
> +	} else {
> +		modinfo->type = ETH_MODULE_SFF_8472;
> +		modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
> +	}
> +
> +	return 0;
> +}
> +
> +static int rtl8169_get_module_eeprom(struct net_device *ndev,
> +				     struct ethtool_eeprom *ee, unsigned char *data)
> +{
> +	struct rtl8169_private *tp = netdev_priv(ndev);
> +	unsigned int first, last, len;
> +	int ret;
> +
> +	if (!tp->sfp_mode)
> +		return -EOPNOTSUPP;
> +
> +	first = ee->offset;
> +	last = ee->offset + ee->len;
> +
> +	if (first < ETH_MODULE_SFF_8079_LEN) {
> +		len = min(last, ETH_MODULE_SFF_8079_LEN);
> +		len -= first;
> +
> +		ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_ID_ADDR,
> +					     first, data, len);
> +		if (ret)
> +			return ret;
> +
> +		first += len;
> +		data += len;
> +	}
> +	if (first < ETH_MODULE_SFF_8472_LEN && last > ETH_MODULE_SFF_8079_LEN) {
> +		len = min(last, ETH_MODULE_SFF_8472_LEN);
> +		len -= first;
> +		first -= ETH_MODULE_SFF_8079_LEN;
> +
> +		ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_DIAGNOSTICS_ADDR,
> +					     first, data, len);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
>  static const struct ethtool_ops rtl8169_ethtool_ops = {
>  	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
>  				     ETHTOOL_COALESCE_MAX_FRAMES,
> @@ -2437,6 +2612,8 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
>  	.set_pauseparam		= rtl8169_set_pauseparam,
>  	.get_eth_mac_stats	= rtl8169_get_eth_mac_stats,
>  	.get_eth_ctrl_stats	= rtl8169_get_eth_ctrl_stats,
> +	.get_module_info	= rtl8169_get_module_info,
> +	.get_module_eeprom	= rtl8169_get_module_eeprom,
>  };
>  
>  static const struct rtl_chip_info *rtl8169_get_chip_version(u32 xid, bool gmii)


^ permalink raw reply

* Re: [PATCH v3 5/5] arm64: dts: qcom: sdm845-google-common: Enable NFC
From: Dmitry Baryshkov @ 2026-04-04 21:05 UTC (permalink / raw)
  To: david
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Alexander Martinz, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Casey Connolly,
	Alexander Martinz, Petr Hodina, biemster, netdev, linux-arm-msm,
	oe-linux-nfc, devicetree, linux-kernel, phone-devel,
	Krzysztof Kozlowski
In-Reply-To: <20260403-oneplus-nfc-v3-5-fbdce57d63c1@ixit.cz>

On Fri, Apr 03, 2026 at 03:58:50PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> Enable NFC controller NXP PN557.
> 
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
>  arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH v3 2/5] arm64: dts: qcom: sdm845-oneplus: Enable NFC
From: Dmitry Baryshkov @ 2026-04-04 21:05 UTC (permalink / raw)
  To: david
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Alexander Martinz, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Casey Connolly,
	Alexander Martinz, Petr Hodina, biemster, netdev, linux-arm-msm,
	oe-linux-nfc, devicetree, linux-kernel, phone-devel,
	Krzysztof Kozlowski
In-Reply-To: <20260403-oneplus-nfc-v3-2-fbdce57d63c1@ixit.cz>

On Fri, Apr 03, 2026 at 03:58:47PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> Enable NFC controller NXP PN553, which is part of the package NXP NQ330
> (NFC + eSE).
> 
> Based on work of biemster <l.j.beemster@gmail.com>.
> 
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
>  .../arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 57 ++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH v3 4/5] arm64: dts: qcom: sdm845-shift-axolotl: Enable NFC
From: Dmitry Baryshkov @ 2026-04-04 21:04 UTC (permalink / raw)
  To: david
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Alexander Martinz, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Casey Connolly,
	Alexander Martinz, Petr Hodina, biemster, netdev, linux-arm-msm,
	oe-linux-nfc, devicetree, linux-kernel, phone-devel,
	Krzysztof Kozlowski
In-Reply-To: <20260403-oneplus-nfc-v3-4-fbdce57d63c1@ixit.cz>

On Fri, Apr 03, 2026 at 03:58:49PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> Enable NFC controller NXP PN553.
> 
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
>  arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts | 52 +++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH v3 3/5] arm64: dts: qcom: sdm845-shift-axolotl: Correct touchscreen sleep state
From: Dmitry Baryshkov @ 2026-04-04 21:02 UTC (permalink / raw)
  To: david
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Alexander Martinz, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Casey Connolly,
	Alexander Martinz, Petr Hodina, biemster, netdev, linux-arm-msm,
	oe-linux-nfc, devicetree, linux-kernel, phone-devel,
	Krzysztof Kozlowski
In-Reply-To: <20260403-oneplus-nfc-v3-3-fbdce57d63c1@ixit.cz>

On Fri, Apr 03, 2026 at 03:58:48PM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
> 
> There is no suspend state in the mainline kernel, use the sleep state
> intended for this purpose.
> 
> Fixes: 45882459159d ("arm64: dts: qcom: sdm845: add device tree for SHIFT6mq")
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
>  arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

^ permalink raw reply

* [PATCH net-next v1] r8169: implement get_module functions for rtl8127atf
From: Fabio Baltieri @ 2026-04-04 20:13 UTC (permalink / raw)
  To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: netdev, linux-kernel, Fabio Baltieri

Implement get_module_info and get_module_eeprom for supported devices,
right now that's the rtl8127atf.

This enables using ethtool to retrieve the transceiver identification
and diagnostic data.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
---

Hi,

Realtek released a new out of tree driver for the rtl8127 and it
includes some code that exposes the I2C controller connected to the SFP
port.

This patch implements get_module_info and get_module_eeprom based on the
information found on that driver, it allows ethtool to fetch the SFP
module information, which is useful both to identify the module and to
track the health of fiber optic transceivers.

The logic for the SFF standard and i2c address selection is borrowed
directly from the aquantia/atlantic driver, I don't have a lot of stuff
to test it but I was able to trigger all code paths from a fiber optic
transceiver and an SFP cable I have available.

Demo:

# Fiber transceiver
$ sudo ethtool -m eth1
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : 10G Ethernet: 10G Base-SR
        Encoding                                  : 0x06 (64B/66B)
        BR Nominal                                : 10300MBd
        Rate identifier                           : 0x00 (unspecified)
        Length (SMF)                              : 0km
        Length (OM2)                              : 80m
        Length (OM1)                              : 30m
        Length (Copper or Active cable)           : 0m
        Length (OM3)                              : 300m
        Laser wavelength                          : 850nm
        Vendor name                               : QSFPTEK
        Vendor OUI                                : 00:0a:0d
        Vendor PN                                 : QT-SFP+-SR
        Vendor rev                                : 
        Option values                             : 0x00 0x1a
        Option                                    : TX_DISABLE implemented
        BR margin max                             : 10%
        BR margin min                             : 88%
        Vendor SN                                 : QT8250805131
        Date code                                 : 250806
        Optical diagnostics support               : Yes
        Laser bias current                        : 5.880 mA
        Laser output power                        : 0.5431 mW / -2.65 dBm
        Receiver signal average optical power     : 0.6912 mW / -1.60 dBm
        Module temperature                        : 20.70 degrees C / 69.25 degrees F
        Module voltage                            : 3.3000 V
...

# DAC
$ sudo ethtool -m eth1
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x21 (Copper pigtail)
        Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x00
        Transceiver type                          : Passive Cable
        Encoding                                  : 0x00 (unspecified)
        BR Nominal                                : 10300MBd
        Rate identifier                           : 0x00 (unspecified)
        Length (SMF)                              : 0km
        Length (OM2)                              : 0m
        Length (OM1)                              : 0m
        Length (Copper or Active cable)           : 1m
        Length (OM3)                              : 0m
        Passive Cu cmplnce.                       : 0x01 (SFF-8431 appendix E [SFF-8472 rev10.4 only])
        Vendor name                               : OEM
        Vendor OUI                                : 00:40:20
        Vendor PN                                 : SFP-H10GB-CU1M
        Vendor rev                                : R
        Option values                             : 0x00 0x00
        BR margin max                             : 0%
        BR margin min                             : 0%
        Vendor SN                                 : CSC240415030053
        Date code                                 : 240508
...

# No module
$ sudo ethtool -m eth1
netlink error: Input/output error

Cheers,
Fabio


 drivers/net/ethernet/realtek/r8169_main.c | 177 ++++++++++++++++++++++
 1 file changed, 177 insertions(+)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 58788d196c57..45ec0b5c1c21 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -2411,6 +2411,181 @@ static int rtl8169_set_link_ksettings(struct net_device *ndev,
 	return 0;
 }
 
+#define R8127_SDS_I2C_CON		0xe200
+#define R8127_SDS_I2C_TAR		0xe204
+#define R8127_SDS_I2C_DATA_CMD		0xe210
+#define R8127_SDS_I2C_FS_SCL_HCNT	0xe21c
+#define R8127_SDS_I2C_FS_SCL_LCNT	0xe220
+#define R8127_SDS_I2C_INTR_STAT		0xe22c
+#define R8127_SDS_I2C_EN		0xe26c
+#define R8127_SDS_I2C_STATUS		0xe270
+
+#define R8127_SDS_I2C_STATUS_ACTIVITY BIT(0)
+#define R8127_SDS_I2C_RX_FIFO_NOT_EMPTY BIT(3)
+#define R8127_SDS_I2C_STAT_TX_ABRT BIT(6)
+
+#define R8127_SDS_I2C_CMD_READ BIT(8)
+#define R8127_SDS_I2C_CMD_STOP BIT(9)
+#define R8127_SDS_I2C_CMD_RESTART BIT(10)
+
+#define SFF_8472_ID_ADDR 0x50
+#define SFF_8472_DIAGNOSTICS_ADDR 0x51
+
+#define SFF_8472_COMP_ADDR      0x5e
+#define SFF_8472_DOM_TYPE_ADDR  0x5c
+
+#define SFF_8472_ADDRESS_CHANGE_REQ_MASK 0x4
+
+static void r8127_sfp_sds_i2c_init(struct rtl8169_private *tp, u8 addr)
+{
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_EN, 0);
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_CON, 0x65);
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_TAR, addr);
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_FS_SCL_HCNT, 0x23a);
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_FS_SCL_LCNT, 0x23a);
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_EN, 1);
+}
+
+static void r8127_sfp_sds_i2c_disable(struct rtl8169_private *tp)
+{
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_EN, 0);
+}
+
+DECLARE_RTL_COND(r8127_sfp_sds_i2c_idle_cond)
+{
+	u16 val;
+
+	val = r8168_mac_ocp_read(tp, R8127_SDS_I2C_STATUS);
+
+	return val & R8127_SDS_I2C_STATUS_ACTIVITY;
+}
+
+DECLARE_RTL_COND(r8127_sfp_sds_i2c_rx_fifo_cond)
+{
+	u16 val;
+
+	val = r8168_mac_ocp_read(tp, R8127_SDS_I2C_STATUS);
+
+	return val & R8127_SDS_I2C_RX_FIFO_NOT_EMPTY;
+}
+
+static int r8127_sfp_sds_i2c_read(struct rtl8169_private *tp,
+				  u8 addr, u8 off, u8 *buf, u16 len)
+{
+	u16 intr_stat;
+	int ret = 0;
+
+	r8127_sfp_sds_i2c_init(tp, addr);
+
+	r8168_mac_ocp_write(tp, R8127_SDS_I2C_DATA_CMD, off);
+
+	if (!rtl_loop_wait_low(tp, &r8127_sfp_sds_i2c_idle_cond, 10, 100)) {
+		ret = -EIO;
+		goto out;
+	}
+
+	intr_stat = r8168_mac_ocp_read(tp, R8127_SDS_I2C_INTR_STAT);
+	if (intr_stat & R8127_SDS_I2C_STAT_TX_ABRT) {
+		/* NACK */
+		ret = -EIO;
+		goto out;
+	}
+
+	for (int i = 0; i < len; i++) {
+		u16 data = R8127_SDS_I2C_CMD_READ;
+
+		if (i == len - 1)
+			data |= R8127_SDS_I2C_CMD_STOP;
+		if (i == 0)
+			data |= R8127_SDS_I2C_CMD_RESTART;
+
+		r8168_mac_ocp_write(tp, R8127_SDS_I2C_DATA_CMD, data);
+
+		if (!rtl_loop_wait_high(tp, &r8127_sfp_sds_i2c_rx_fifo_cond,
+					10, 1000)) {
+			ret = -ETIMEDOUT;
+			goto out;
+		}
+
+		buf[i] = r8168_mac_ocp_read(tp, R8127_SDS_I2C_DATA_CMD);
+	}
+
+out:
+	r8127_sfp_sds_i2c_disable(tp);
+
+	return ret;
+}
+
+static int rtl8169_get_module_info(struct net_device *ndev,
+				   struct ethtool_modinfo *modinfo)
+{
+	struct rtl8169_private *tp = netdev_priv(ndev);
+	u8 compliance_val, dom_type;
+	int ret;
+
+	if (!tp->sfp_mode)
+		return -EOPNOTSUPP;
+
+	ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_ID_ADDR,
+				     SFF_8472_COMP_ADDR, &compliance_val, 1);
+	if (ret)
+		return ret;
+
+	ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_ID_ADDR,
+				     SFF_8472_DOM_TYPE_ADDR, &dom_type, 1);
+	if (ret)
+		return ret;
+
+	if (dom_type & SFF_8472_ADDRESS_CHANGE_REQ_MASK || compliance_val == 0x00) {
+		modinfo->type = ETH_MODULE_SFF_8079;
+		modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
+	} else {
+		modinfo->type = ETH_MODULE_SFF_8472;
+		modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
+	}
+
+	return 0;
+}
+
+static int rtl8169_get_module_eeprom(struct net_device *ndev,
+				     struct ethtool_eeprom *ee, unsigned char *data)
+{
+	struct rtl8169_private *tp = netdev_priv(ndev);
+	unsigned int first, last, len;
+	int ret;
+
+	if (!tp->sfp_mode)
+		return -EOPNOTSUPP;
+
+	first = ee->offset;
+	last = ee->offset + ee->len;
+
+	if (first < ETH_MODULE_SFF_8079_LEN) {
+		len = min(last, ETH_MODULE_SFF_8079_LEN);
+		len -= first;
+
+		ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_ID_ADDR,
+					     first, data, len);
+		if (ret)
+			return ret;
+
+		first += len;
+		data += len;
+	}
+	if (first < ETH_MODULE_SFF_8472_LEN && last > ETH_MODULE_SFF_8079_LEN) {
+		len = min(last, ETH_MODULE_SFF_8472_LEN);
+		len -= first;
+		first -= ETH_MODULE_SFF_8079_LEN;
+
+		ret = r8127_sfp_sds_i2c_read(tp, SFF_8472_DIAGNOSTICS_ADDR,
+					     first, data, len);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
 				     ETHTOOL_COALESCE_MAX_FRAMES,
@@ -2437,6 +2612,8 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.set_pauseparam		= rtl8169_set_pauseparam,
 	.get_eth_mac_stats	= rtl8169_get_eth_mac_stats,
 	.get_eth_ctrl_stats	= rtl8169_get_eth_ctrl_stats,
+	.get_module_info	= rtl8169_get_module_info,
+	.get_module_eeprom	= rtl8169_get_module_eeprom,
 };
 
 static const struct rtl_chip_info *rtl8169_get_chip_version(u32 xid, bool gmii)
-- 
2.47.3


^ permalink raw reply related

* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Dmitry Baryshkov @ 2026-04-04 19:39 UTC (permalink / raw)
  To: Umang Chheda
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
	linux-kernel, netdev
In-Reply-To: <4d32e86f-353c-4951-89ca-46aa49d60f76@oss.qualcomm.com>

On Sat, Apr 04, 2026 at 04:15:54PM +0530, Umang Chheda wrote:
> 
> 
> On 4/4/2026 1:58 AM, Dmitry Baryshkov wrote:
> > On Fri, Apr 03, 2026 at 04:14:28PM +0530, Umang Chheda wrote:
> >> Hello Dmitry,
> >>
> >> On 4/1/2026 5:06 PM, Dmitry Baryshkov wrote:
> >>> On Wed, Apr 01, 2026 at 12:14:42AM +0530, Umang Chheda wrote:
> >>>> Introduce bindings for the monaco-evk-ac IoT board, which is
> >>>> based on the monaco-ac (QCS8300-AC) SoC variant.
> >>>
> >>> If it is a different SoC SKU, should it be reflected in the SoC compat
> >>> strings?
> >>
> >> Monaco‑AC does not introduce any S/W differences compared to Monaco SoC
> >> -- All IP blocks and bindings remain identical from S/W PoV, Hence
> >> haven't included the SoC SKU in the SoC compat strings.
> >>
> >> Hope this is okay ? Your view on this ?
> > 
> > You are descibing -AC as the main difference between the kits, but then
> > you say that -AC doesn't bring new software interfaces. What is the
> > difference then between monako-evk and the -ac variant?
> > 
> 
> The major difference between monaco-evk and monaco-ac-evk boards is that
> of power grid. monaco-evk requires 4 PMICs (2x PM8650AU + Maxim MAX20018
> + TI TPS6594) to support higher power requirements of monaco-AA variant
> of SoC which supports upto 40 TOPS of NPU - whereas this board
> "monaco-ac-evk" supports 20 TOPS of NPU and has lesser power
> requirements hence 2 PMICs suffice the power requirements (2x PM8650AU).

Is that the only difference? Is the PCB the same? Should we have a
single common file for those two variants?

> 
> 
> > Also, from the naming point of view, it is monako-ac-evk, not the other
> > way.
> 
> Ack, will change this to "monaco-ac-evk" in the next version.
> 
> Also, should I change DT name "monaco-ac-sku.dts" instead of current
> "monaco-evk-ac-sku" ?

monako-ac-evk.dtsi.

> 
> > 
> >>
> >>>
> >>>>
> >>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> >>>>  1 file changed, 1 insertion(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> index ca880c105f3b..c76365a89687 100644
> >>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> @@ -918,6 +918,7 @@ properties:
> >>>>            - enum:
> >>>>                - arduino,monza
> >>>>                - qcom,monaco-evk
> >>>> +              - qcom,monaco-evk-ac
> >>>>                - qcom,qcs8300-ride
> >>>>            - const: qcom,qcs8300
> >>>>  
> >>>>
> >>>> -- 
> >>>> 2.34.1
> >>>>
> >>>
> >>
> >> Thanks,
> >> Umang
> > 
> 
> Thanks,
> Umang
> 
> 

-- 
With best wishes
Dmitry

^ permalink raw reply

* Re: [PATCH v2 2/2] selftests: net: add act_nat ICMP inner checksum test
From: Jakub Kicinski @ 2026-04-04 18:01 UTC (permalink / raw)
  To: David Carlier
  Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
	Herbert Xu, netdev, stable
In-Reply-To: <20260404120310.88218-2-devnexen@gmail.com>

On Sat,  4 Apr 2026 13:03:10 +0100 David Carlier wrote:
> Verify that act_nat correctly updates the inner IP header
> checksum when rewriting addresses inside ICMP error payloads.
> 
> The test sets up two namespaces with act_nat on a veth pair,
> triggers an ICMP destination unreachable, and validates the
> inner IP header checksum in the received ICMP error.
> 
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
>  tools/testing/selftests/net/Makefile          |   1 +

you need to add the CONFIG* dependencies to the relevant config file.

^ permalink raw reply

* [PATCH] nfc: nci: fix OOB heap read in nci_core_init_rsp_packet_v2()
From: Lekë Hapçiu @ 2026-04-04 18:00 UTC (permalink / raw)
  To: netdev; +Cc: gregkh, linux-nfc, davem, kuba, Lekë Hapçiu

From: Lekë Hapçiu <framemain@outlook.com>

nci_core_init_rsp_packet_v2() walks the chip-supplied
supported_rf_interfaces[] flexible array using a plain pointer
with no bounds check.  Each iteration advances supported_rf_interface
by (1 + 1 + rf_extension_cnt) bytes, where rf_extension_cnt comes
directly from the chip.  A hostile NCI v2 chip can set
rf_extension_cnt=255 per entry and num_supported_rf_interfaces=4,
driving the pointer up to ~1028 bytes past the end of the skb into
adjacent kernel heap.

Add two guards per loop iteration:
 - check that at least 2 bytes remain before reading the interface
   byte and extension count byte;
 - check that sufficient bytes remain for the declared extension
   block before advancing over it.

Also add an upfront sizeof(*rsp) check so that accessing the fixed
header fields (nfcc_features, max_logical_connections, ...) is safe
before the loop is reached.

Fixes: bcd684aace34 ("net/nfc/nci: Support NCI 2.x initial sequence")
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
 net/nfc/nci/rsp.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
index 4aaf362b9..ecd360b59 100644
--- a/net/nfc/nci/rsp.c
+++ b/net/nfc/nci/rsp.c
@@ -96,10 +96,17 @@ static u8 nci_core_init_rsp_packet_v2(struct nci_dev *ndev,
 				      const struct sk_buff *skb)
 {
 	const struct nci_core_init_rsp_nci_ver2 *rsp = (void *)skb->data;
-	const u8 *supported_rf_interface = rsp->supported_rf_interfaces;
+	const u8 *supported_rf_interface;
+	const u8 *end = skb->data + skb->len;
 	u8 rf_interface_idx = 0;
 	u8 rf_extension_cnt = 0;
 
+	if (skb->len < sizeof(*rsp)) {
+		pr_err("CORE_INIT_RSP v2 too short: len=%u need=%zu\n",
+		       skb->len, sizeof(*rsp));
+		return NCI_STATUS_SYNTAX_ERROR;
+	}
+
 	pr_debug("status %x\n", rsp->status);
 
 	if (rsp->status != NCI_STATUS_OK)
@@ -112,11 +119,22 @@ static u8 nci_core_init_rsp_packet_v2(struct nci_dev *ndev,
 		min((int)ndev->num_supported_rf_interfaces,
 		    NCI_MAX_SUPPORTED_RF_INTERFACES);
 
+	supported_rf_interface = rsp->supported_rf_interfaces;
 	while (rf_interface_idx < ndev->num_supported_rf_interfaces) {
+		if (supported_rf_interface + 2 > end) {
+			pr_err("CORE_INIT_RSP v2 truncated at rf_interface %d\n",
+			       rf_interface_idx);
+			return NCI_STATUS_SYNTAX_ERROR;
+		}
 		ndev->supported_rf_interfaces[rf_interface_idx++] = *supported_rf_interface++;
 
 		/* skip rf extension parameters */
 		rf_extension_cnt = *supported_rf_interface++;
+		if (supported_rf_interface + rf_extension_cnt > end) {
+			pr_err("CORE_INIT_RSP v2 rf_extension overflow at idx %d\n",
+			       rf_interface_idx - 1);
+			return NCI_STATUS_SYNTAX_ERROR;
+		}
 		supported_rf_interface += rf_extension_cnt;
 	}
 
-- 
2.51.0


^ permalink raw reply related

* Re: [PATCH net] ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()
From: Justin Iurman @ 2026-04-04 17:32 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Jakub Kicinski, davem, pabeni, horms, dsahern, netdev,
	eric.dumazet, yimingqian591
In-Reply-To: <CANn89i+QK6cWseXBAbwZaWcUGG6n+CbuWV-4b97x2LmDJoGjTQ@mail.gmail.com>

On 4/4/26 13:44, Eric Dumazet wrote:
> On Sat, Apr 4, 2026 at 3:13 AM Justin Iurman <justin.iurman@gmail.com> wrote:
>>
>> On 4/3/26 23:50, Jakub Kicinski wrote:
>>> On Fri, 3 Apr 2026 14:47:32 -0700 Eric Dumazet wrote:
>>>>> If the ingress device has more RX queues than the egress device (dev) has
>>>>> TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues.
>>>>>
>>>>> Since skb_get_tx_queue() does not clamp the index, will it return an
>>>>> out-of-bounds pointer into the egress device's dev->_tx array, causing
>>>>> dereferencing queue->qdisc to read invalid memory?
>>>>
>>>> This seems a different bug ?
>>>>
>>>> I mean, do we need to fix all bug in a single patch ?
>>>
>>> no no, sorry, i'm just sending this out for Justin or you as a separate
>>> thing.
>>
>> Thanks Jakub, I don't know how I missed that. It's not just about a
>> possible OOB: it's actually incorrect for IOAM to do that because we're
>> relying on a lucky assumption at best (i.e., if queue_mapping on RX ==
>> queue_mapping on TX). This unfortunately rules out the possibility to
>> have an accurate per queue visibility (which I originally provided for
>> flexibility). I've had a local patch for a long time to aggregate the
>> queue depth (i.e., sum of all TX queues). It is more expensive(***), but
>> it would kill two birds with one stone and solve both problems
>> simultaneously.
>>
>> Jakub, Eric, please let me know if the following plan works for both of you:
>> - (net) fix the OOB reported by Jakub (and, while at it, add missing
>> locks around qdisc_qstats_qlen_backlog() -> also included in my local patch)
>> - (net-next) after the merge window, add the new feature
>>
>> After that, the per queue visibility would be considered
>> legacy/deprecated and not the default behavior. Documentation would be
>> updated accordingly to explain why per queue visibility cannot be trusted.
>>
>>    (***) the advise to operators in such a case is (obviously) to reduce
>> the IOAM insertion (with the frequency parameter), especially at line rate.
> 
> Getting qdisc stats can be expensive for qdisc with per-cpu storage
> for counters like pfifo-fast.
> 
> If your plan is to sum MQ stats, this could have quadratic behavior :
> O(nr_cpus ^ 2)
> 
> I suggest rate-limiting this very expensive operation, or OAM will
> become a nice DOS tool.
> (Ie not depend on operators being nice, enforce this on the hosts)

Makes sense, I agree. But then rate-limiting would be redundant with the 
frequency of IOAM insertion, which acts as a rate-limit on its own 
already. IOAM is not (never ever) enabled by default, it must be enabled 
on ingress interface(s) explicitly, and configured accordingly. So it 
rules out the need to enforce anything on "hosts", as it is assumed you 
know what you're doing when you enable something (***). Also, IOAM only 
runs inside a limited domain (i.e., private/administrative domain 
operated by the same person/entity). Traffic must be filtered on the 
ingress of the domain (i.e., no IOAM injection from the outside), on the 
egress of the domain (i.e., prevent potential data leaking due to, e.g., 
misconfiguration), and the frequency of IOAM insertion actually is the 
rate-limit inside the domain (to each their own configuration, depending 
on performance). This is why I believe that documenting the whole thing 
would be enough in this case, since we already have rate-limiting thanks 
to the frequency of IOAM insertion.

(***) well, we may add another security barrier, just in case someone 
enables IOAM by mistake, by disabling the queue depth by default.

^ permalink raw reply

* Re: [PATCH net-next v2 0/5] net: bridge: mcast: add multicast exponential field encoding
From: Ujjal Roy @ 2026-04-04 17:25 UTC (permalink / raw)
  To: Ido Schimmel
  Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
	Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, Kernel,
	Kernel, linux-kselftest
In-Reply-To: <20260331141647.GB1637150@shredder>

On Tue, Mar 31, 2026, 7:47 PM Ido Schimmel <idosch@nvidia.com> wrote:
>
> On Mon, Mar 30, 2026 at 07:16:06PM +0000, Ujjal Roy wrote:
> > Description:
> > This series addresses a mismatch in how multicast query
> > intervals and response codes are handled across IPv4 (IGMPv3)
> > and IPv6 (MLDv2). While decoding logic currently exists,
> > the corresponding encoding logic is missing during query
> > packet generation. This leads to incorrect intervals being
> > transmitted when values exceed their linear thresholds.
>
> Thanks for the patches. I will take a look, but please read:
>
> https://docs.kernel.org/process/maintainer-netdev.html
>
> In particular:
>
> "The new version of patches should be posted as a separate thread, not
> as a reply to the previous posting."

I have updated the cover letter title and sent the new version as a
separate thread. The same can be found here in this link:
https://lore.kernel.org/all/20260403150050.1235-1-royujjal@gmail.com/

^ permalink raw reply

* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Rafael J. Wysocki @ 2026-04-04 17:11 UTC (permalink / raw)
  To: Douglas Anderson
  Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
	Alan Stern, Saravana Kannan, Christoph Hellwig, Eric Dumazet,
	Johan Hovold, Leon Romanovsky, Alexander Lobakin,
	Alexey Kardashevskiy, Robin Murphy, Andrew Morton, Frank.Li,
	Jason Gunthorpe, alex, alexander.stein, andre.przywara, andrew,
	andrew, andriy.shevchenko, aou, ardb, bhelgaas, brgl, broonie,
	catalin.marinas, chleroy, davem, david, devicetree, dmaengine,
	driver-core, gbatra, gregory.clement, hkallweit1, iommu,
	jirislaby, joel, joro, kees, kevin.brodsky, kuba, lenb, lgirdwood,
	linux-acpi, linux-arm-kernel, linux-aspeed, linux-cxl,
	linux-kernel, linux-mips, linux-mm, linux-pci, linux-riscv,
	linux-serial, linux-snps-arc, linux-usb, linux, linuxppc-dev,
	m.szyprowski, maddy, mani, maz, miko.lenczewski, mpe, netdev,
	npiggin, osalvador, oupton, pabeni, palmer, peter.ujfalusi,
	peterz, pjw, robh, sebastian.hesselbarth, tglx, tsbogend, vgupta,
	vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <20260404000644.522677-1-dianders@chromium.org>

On Sat, Apr 4, 2026 at 2:07 AM Douglas Anderson <dianders@chromium.org> wrote:
>
> The main goal of this series is to fix the observed bug talked about
> in the first patch ("driver core: Don't let a device probe until it's
> ready"). That patch fixes a problem that has been observed in the real
> world and could land even if the rest of the patches are found
> unacceptable or need to be spun.
>
> That said, during patch review Danilo correctly pointed out that many
> of the bitfield accesses in "struct device" are unsafe. I added a
> bunch of patches in the series to address each one.
>
> Danilo said he's most worried about "can_match", so I put that one
> first. After that, I tried to transition bitfields to flags in reverse
> order to when the bitfield was added.
>
> Even if transitioning from bitfields to flags isn't truly needed for
> correctness, it seems silly (and wasteful of space in struct device)
> to have some in bitfields and some as flags. Thus I didn't spend time
> for each bitfield showing that it's truly needed for correctness.
>
> Transition was done semi manually. Presumably someone skilled at
> coccinelle could do a better job, but I just used sed in a heavy-
> handed manner and then reviewed/fixed the results, undoing anything my
> script got wrong. My terrible/ugly script was:
>
> var=can_match
> caps="${var^^}"
> for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
>   echo $f
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
>   sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
> done
>
> From v3 to v4, I transitioned to accessor functions with another ugly
> sed script. I had git format the old patches, then transformed them
> with:
>
> for f in *.patch; do
>   echo $f
>   sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
>   sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
>   sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> done
>
> ...and then did a few manual touchups for spacing.
>
> NOTE: one potentially "controversial" choice I made in some patches
> was to always reserve a flag ID even if a flag is only used under
> certain CONFIG_ settings. This is a change from how things were
> before. Keeping the numbering consistent and allowing easy
> compile-testing of both CONFIG settings seemed worth it, especially
> since it won't take up any extra space until we've added a lot more
> flags.
>
> I only marked the first patch as a "Fix" since it is the only one
> fixing observed problems. Other patches could be considered fixes too
> if folks want.
>
> I tested the first patch in the series backported to kernel 6.6 on the
> Pixel phone that was experiencing the race. I added extra printouts to
> make sure that the problem was hitting / addressed. The rest of the
> patches are tested with allmodconfig with arm32, arm64, ppc, and
> x86. I boot tested on an arm64 Chromebook running mainline.
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - Use a new "flags" bitfield
> - Add missing \n in probe error message
>
> Changes in v2:
> - Instead of adjusting the ordering, use "ready_to_probe" flag
>
> Douglas Anderson (9):
>   driver core: Don't let a device probe until it's ready
>   driver core: Replace dev->can_match with dev_can_match()
>   driver core: Replace dev->dma_iommu with dev_dma_iommu()
>   driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
>   driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
>   driver core: Replace dev->state_synced with dev_state_synced()
>   driver core: Replace dev->dma_coherent with dev_dma_coherent()
>   driver core: Replace dev->of_node_reused with dev_of_node_reused()
>   driver core: Replace dev->offline + ->offline_disabled with accessors
>
>  arch/arc/mm/dma.c                             |   4 +-
>  arch/arm/mach-highbank/highbank.c             |   2 +-
>  arch/arm/mach-mvebu/coherency.c               |   2 +-
>  arch/arm/mm/dma-mapping-nommu.c               |   4 +-
>  arch/arm/mm/dma-mapping.c                     |  28 ++--
>  arch/arm64/kernel/cpufeature.c                |   2 +-
>  arch/arm64/mm/dma-mapping.c                   |   2 +-
>  arch/mips/mm/dma-noncoherent.c                |   2 +-
>  arch/powerpc/kernel/dma-iommu.c               |   8 +-
>  .../platforms/pseries/hotplug-memory.c        |   4 +-
>  arch/riscv/mm/dma-noncoherent.c               |   2 +-
>  drivers/acpi/scan.c                           |   2 +-
>  drivers/base/core.c                           |  53 +++++---
>  drivers/base/cpu.c                            |   4 +-
>  drivers/base/dd.c                             |  28 ++--
>  drivers/base/memory.c                         |   2 +-
>  drivers/base/pinctrl.c                        |   2 +-
>  drivers/base/platform.c                       |   2 +-
>  drivers/dma/ti/k3-udma-glue.c                 |   6 +-
>  drivers/dma/ti/k3-udma.c                      |   6 +-
>  drivers/iommu/dma-iommu.c                     |   9 +-
>  drivers/iommu/iommu.c                         |   5 +-
>  drivers/net/pcs/pcs-xpcs-plat.c               |   2 +-
>  drivers/of/device.c                           |   6 +-
>  drivers/pci/of.c                              |   2 +-
>  drivers/pci/pwrctrl/core.c                    |   2 +-
>  drivers/regulator/bq257xx-regulator.c         |   2 +-
>  drivers/regulator/rk808-regulator.c           |   2 +-
>  drivers/tty/serial/serial_base_bus.c          |   2 +-
>  drivers/usb/gadget/udc/aspeed-vhub/dev.c      |   2 +-
>  include/linux/device.h                        | 120 ++++++++++++------
>  include/linux/dma-map-ops.h                   |   6 +-
>  include/linux/dma-mapping.h                   |   2 +-
>  include/linux/iommu-dma.h                     |   3 +-
>  kernel/cpu.c                                  |   4 +-
>  kernel/dma/mapping.c                          |  12 +-
>  mm/hmm.c                                      |   2 +-
>  37 files changed, 206 insertions(+), 142 deletions(-)
>
> --

For the whole set

Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>

^ permalink raw reply

* [PATCH v3 1/1] Bluetooth: serialize accept_q access
From: Ren Wei @ 2026-04-04 16:23 UTC (permalink / raw)
  To: linux-bluetooth, netdev
  Cc: Paul Menzel, marcel, luiz.dentz, davem, edumazet, kuba, pabeni,
	horms, yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
	wangjiexun2025, n05ec
In-Reply-To: <cover.1774454568.git.wangjiexun2025@gmail.com>

From: Jiexun Wang <wangjiexun2025@gmail.com>

bt_sock_poll() walks the accept queue without synchronization, while
child teardown can unlink the same socket and drop its last reference.

Protect accept_q with a dedicated lock for queue updates and polling.
Also rework bt_accept_dequeue() to take temporary child references under
the queue lock before dropping it and locking the child socket.

Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
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: Jiexun Wang <wangjiexun2025@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
Changes in v3:
- move sk_acceptq_added()/sk_acceptq_removed() inside accept_q_lock
  critical sections to serialize sk_ack_backlog updates with accept_q
  operations

Changes in v2:
- add Tested-by: Ren Wei <enjou1224z@gmail.com>
- resend to the public Bluetooth/netdev lists

 include/net/bluetooth/bluetooth.h |  1 +
 net/bluetooth/af_bluetooth.c      | 87 +++++++++++++++++++++++--------
 2 files changed, 66 insertions(+), 22 deletions(-)

diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 69eed69f7f26..3faea66b1979 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -398,6 +398,7 @@ void baswap(bdaddr_t *dst, const bdaddr_t *src);
 struct bt_sock {
 	struct sock sk;
 	struct list_head accept_q;
+	spinlock_t accept_q_lock; /* protects accept_q */
 	struct sock *parent;
 	unsigned long flags;
 	void (*skb_msg_name)(struct sk_buff *, void *, int *);
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 2b94e2077203..fa14b9a915eb 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -154,6 +154,7 @@ struct sock *bt_sock_alloc(struct net *net, struct socket *sock,
 
 	sock_init_data(sock, sk);
 	INIT_LIST_HEAD(&bt_sk(sk)->accept_q);
+	spin_lock_init(&bt_sk(sk)->accept_q_lock);
 
 	sock_reset_flag(sk, SOCK_ZAPPED);
 
@@ -214,6 +215,7 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
 {
 	const struct cred *old_cred;
 	struct pid *old_pid;
+	struct bt_sock *par = bt_sk(parent);
 
 	BT_DBG("parent %p, sk %p", parent, sk);
 
@@ -224,9 +226,13 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
 	else
 		lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
 
-	list_add_tail(&bt_sk(sk)->accept_q, &bt_sk(parent)->accept_q);
 	bt_sk(sk)->parent = parent;
 
+	spin_lock_bh(&par->accept_q_lock);
+	list_add_tail(&bt_sk(sk)->accept_q, &par->accept_q);
+	sk_acceptq_added(parent);
+	spin_unlock_bh(&par->accept_q_lock);
+
 	/* Copy credentials from parent since for incoming connections the
 	 * socket is allocated by the kernel.
 	 */
@@ -244,8 +250,6 @@ void bt_accept_enqueue(struct sock *parent, struct sock *sk, bool bh)
 		bh_unlock_sock(sk);
 	else
 		release_sock(sk);
-
-	sk_acceptq_added(parent);
 }
 EXPORT_SYMBOL(bt_accept_enqueue);
 
@@ -254,45 +258,72 @@ EXPORT_SYMBOL(bt_accept_enqueue);
  */
 void bt_accept_unlink(struct sock *sk)
 {
+	struct sock *parent = bt_sk(sk)->parent;
+
 	BT_DBG("sk %p state %d", sk, sk->sk_state);
 
+	spin_lock_bh(&bt_sk(parent)->accept_q_lock);
 	list_del_init(&bt_sk(sk)->accept_q);
-	sk_acceptq_removed(bt_sk(sk)->parent);
+	sk_acceptq_removed(parent);
+	spin_unlock_bh(&bt_sk(parent)->accept_q_lock);
 	bt_sk(sk)->parent = NULL;
 	sock_put(sk);
 }
 EXPORT_SYMBOL(bt_accept_unlink);
 
+static struct sock *bt_accept_get(struct sock *parent, struct sock *sk)
+{
+	struct bt_sock *bt = bt_sk(parent);
+	struct sock *next = NULL;
+
+	/* accept_q is modified from child teardown paths too, so take a
+	 * temporary reference before dropping the queue lock.
+	 */
+	spin_lock_bh(&bt->accept_q_lock);
+
+	if (sk) {
+		if (bt_sk(sk)->parent != parent)
+			goto out;
+
+		if (!list_is_last(&bt_sk(sk)->accept_q, &bt->accept_q)) {
+			next = &list_next_entry(bt_sk(sk), accept_q)->sk;
+			sock_hold(next);
+		}
+	} else if (!list_empty(&bt->accept_q)) {
+		next = &list_first_entry(&bt->accept_q,
+					 struct bt_sock, accept_q)->sk;
+		sock_hold(next);
+	}
+
+out:
+	spin_unlock_bh(&bt->accept_q_lock);
+	return next;
+}
+
 struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
 {
-	struct bt_sock *s, *n;
-	struct sock *sk;
+	struct sock *sk, *next;
 
 	BT_DBG("parent %p", parent);
 
 restart:
-	list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
-		sk = (struct sock *)s;
-
+	for (sk = bt_accept_get(parent, NULL); sk; sk = next) {
 		/* Prevent early freeing of sk due to unlink and sock_kill */
-		sock_hold(sk);
 		lock_sock(sk);
 
 		/* Check sk has not already been unlinked via
 		 * bt_accept_unlink() due to serialisation caused by sk locking
 		 */
-		if (!bt_sk(sk)->parent) {
+		if (bt_sk(sk)->parent != parent) {
 			BT_DBG("sk %p, already unlinked", sk);
 			release_sock(sk);
 			sock_put(sk);
 
-			/* Restart the loop as sk is no longer in the list
-			 * and also avoid a potential infinite loop because
-			 * list_for_each_entry_safe() is not thread safe.
-			 */
 			goto restart;
 		}
 
+		next = bt_accept_get(parent, sk);
+
 		/* sk is safely in the parent list so reduce reference count */
 		sock_put(sk);
 
@@ -310,6 +341,8 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
 				sock_graft(sk, newsock);
 
 			release_sock(sk);
+			if (next)
+				sock_put(next);
 			return sk;
 		}
 
@@ -518,18 +551,28 @@ EXPORT_SYMBOL(bt_sock_stream_recvmsg);
 
 static inline __poll_t bt_accept_poll(struct sock *parent)
 {
-	struct bt_sock *s, *n;
+	struct bt_sock *bt = bt_sk(parent);
+	struct bt_sock *s;
 	struct sock *sk;
+	__poll_t mask = 0;
+
+	spin_lock_bh(&bt->accept_q_lock);
+	list_for_each_entry(s, &bt->accept_q, accept_q) {
+		int state;
 
-	list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
 		sk = (struct sock *)s;
-		if (sk->sk_state == BT_CONNECTED ||
-		    (test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags) &&
-		     sk->sk_state == BT_CONNECT2))
-			return EPOLLIN | EPOLLRDNORM;
+		state = READ_ONCE(sk->sk_state);
+
+		if (state == BT_CONNECTED ||
+		    (test_bit(BT_SK_DEFER_SETUP, &bt->flags) &&
+		     state == BT_CONNECT2)) {
+			mask = EPOLLIN | EPOLLRDNORM;
+			break;
+		}
 	}
+	spin_unlock_bh(&bt->accept_q_lock);
 
-	return 0;
+	return mask;
 }
 
 __poll_t bt_sock_poll(struct file *file, struct socket *sock,
-- 
2.34.1


^ permalink raw reply related

* Re: [PATCH v9 00/10] VMSCAPE optimization for BHI variant
From: David Laight @ 2026-04-04 15:20 UTC (permalink / raw)
  To: Pawan Gupta
  Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
	David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
	Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
	Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
	Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
	John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
	Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
	netdev, linux-doc
In-Reply-To: <20260402-vmscape-bhb-v9-0-94d16bc29774@linux.intel.com>

On Thu, 2 Apr 2026 17:30:32 -0700
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:

> v9:
> - Use global variables for BHB loop counters instead of ALTERNATIVE-based
>   approach. (Dave & others)
> - Use 32-bit registers (%eax/%ecx) for loop counters, loaded via movzbl
>   from 8-bit globals. 8-bit registers (e.g. %ah in the inner loop) caused
>   performance regression on certain CPUs due to partial-register stalls. (David Laight)
> - Let BPF save/restore %rax/%rcx as in the original implementation, since
>   it is the only caller that needs these registers preserved across the
>   BHB clearing sequence.

That is as dangerous as hell...
Does BPF even save %rcx - I'm sure I checked that a long time ago
and found it didn't.
(I'm mostly AFK over Easter and can't check.)
A least there should be a blood great big comment that BPF calls this code
and only saves specific registers.
But given the number of mispredicted branches and other pipeline stalls
in this code a couple of register saves to stack are unlikely to make
any difference.

	David


^ permalink raw reply

* Re: [PATCH v2] treewide: use get_random_u{16,32,64}() where appropriate
From: Andrew Lunn @ 2026-04-04 15:17 UTC (permalink / raw)
  To: David Carlier
  Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, Christian Brauner, Kuniyuki Iwashima, Jan Kara,
	Jeff Layton, Qiliang Yuan, netdev
In-Reply-To: <20260404120043.85411-1-devnexen@gmail.com>

On Sat, Apr 04, 2026 at 01:00:43PM +0100, David Carlier wrote:
> Use the typed random integer helpers instead of
> get_random_bytes() when filling a single integer variable.
> The helpers return the value directly, require no pointer
> or size argument, and better express intent.
> 
> Skipped sites writing into __be16 fields (netdevsim) where
> a direct assignment would trigger sparse endianness warnings.
> 
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
>  drivers/block/drbd/drbd_main.c                   | 4 ++--
>  drivers/block/drbd/drbd_nl.c                     | 2 +-
>  drivers/gpu/drm/i915/i915_hdcp_gsc.c             | 2 +-
>  drivers/gpu/drm/xe/xe_gsc_submit.c               | 2 +-
>  drivers/md/dm-vdo/indexer/index-layout.c         | 2 +-
>  drivers/net/netdevsim/psample.c                  | 4 ++--
>  drivers/target/iscsi/iscsi_target_seq_pdu_list.c | 2 +-
>  fs/ext2/super.c                                  | 2 +-
>  fs/ocfs2/super.c                                 | 2 +-
>  net/ceph/auth_x.c                                | 2 +-
>  net/core/net_namespace.c                         | 2 +-
>  net/mac80211/mesh_plink.c                        | 2 +-
>  net/mptcp/subflow.c                              | 4 ++--
>  net/openvswitch/flow_table.c                     | 2 +-
>  net/sctp/sm_make_chunk.c                         | 4 ++--
>  net/tipc/node.c                                  | 2 +-

Hi David

You are more likely to get this merged if you break it up per
subsystem.

    Andrew

---
pw-bot: cr

^ permalink raw reply

* Re: [net-next PATCH 04/10] bitfield.h: add FIELD_WIDTH()
From: David Laight @ 2026-04-04 15:12 UTC (permalink / raw)
  To: Luiz Angelo Daros de Luca
  Cc: Yury Norov, Andrew Lunn, Vladimir Oltean, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
	Linus Walleij, Alvin Šipraga, Yury Norov, Rasmus Villemoes,
	Russell King, netdev, linux-kernel
In-Reply-To: <CAJq09z5kMu4ANp3n2Q0C1j8TULdCKW_yPM=nN78mNupAt51YGQ@mail.gmail.com>

On Fri, 3 Apr 2026 11:09:30 -0300
Luiz Angelo Daros de Luca <luizluca@gmail.com> wrote:

> Thanks David and Yuri,
> 
> This patch was originally intended to reconstruct a value split across
> multiple registers. Originally:
> 
>         vlan4k->member =
>                FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK, data[0]) |
>                (FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2])
>                 << FIELD_WIDTH(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK));

That calculation isn't even really correct.
It is only right if the low bit of the last mask is set.

I'm not a big fan of FIELD_GET/PREP - they have their use, but get
overused.

	David


> 
> However, as Yuri pointed out, I can use FIELD_PREP() to align the bits
> into the final struct member without manual bitops. While less common,
> this pattern is used elsewhere (e.g., drivers/clk/clk-lmk04832.c). The
> updated approach would be:
> 
>         vlan4k->member =
>                FIELD_PREP(RTL8365MB_CVLAN_MBR_LO_MASK,
>                           FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK,
> data[0])) |
>                FIELD_PREP(RTL8365MB_CVLAN_MBR_HI_MASK,
> 
> FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2]));
> 
> If this use of FIELD_PREP is preferred, I will drop this FIELD_WIDTH
> patch from the series as it would no longer have any users.
> 
> Regards,
> 
> Luiz
> 


^ permalink raw reply

* Re: [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Andrew Lunn @ 2026-04-04 15:11 UTC (permalink / raw)
  To: Birger Koblitz
  Cc: Greg KH, Jakub Kicinski, Andrew Lunn, David S. Miller,
	Eric Dumazet, Paolo Abeni, linux-usb, netdev, linux-kernel,
	Chih Kai Hsu
In-Reply-To: <23860a3b-5c89-42d8-bf7f-2f77f35cf14a@birger-koblitz.de>

> Thanks for the feedback, Greg!
> the underlying issue is that parts of the patch I submitted are now also
> submitted by others, and that gets fast-tracked. This has now happened twice,
> and I am being told every time to re-submit, without efforts to coordinate
> this, or hints that this pattern may stop. This has somewhat made me loose
> trust in the process.

It is somewhat on you to coordinate with others working on the same
driver.

As is often said, Maintainers are overloaded, and push whatever they
can onto developers. It should not need a Maintainer to get developers
to coordinate, they should be able to do that on there own. Since you
are subscribed to the netdev list, you can see the patches flying by,
you know who else is working on this driver. Please go talk to them.

    Andrew

^ permalink raw reply

* Re: [net-next v2 3/3] selftests/net: Test PACKET_AUXDATA
From: Willem de Bruijn @ 2026-04-04 15:10 UTC (permalink / raw)
  To: Joe Damato, netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Simon Horman, Shuah Khan
  Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260403233240.178948-4-joe@dama.to>

Joe Damato wrote:
> Extend the packet socket selftest, adding a recvmsg path, to test
> PACKET_AUXDATA. Check basic attributes of tpacket_auxdata.
> 
> Signed-off-by: Joe Damato <joe@dama.to>

> @@ -322,8 +376,11 @@ static void parse_opts(int argc, char **argv)
>  {
>  	int c;
>  
> -	while ((c = getopt(argc, argv, "bcCdDgl:qt:vV")) != -1) {
> +	while ((c = getopt(argc, argv, "abcCdDgl:qt:vV")) != -1) {
>  		switch (c) {
> +		case 'a':
> +			cfg_aux_data = true;
> +			break;

These are intended as independent test cases: test_auxdata,
test_drops. By using flags the flags can be combined. Are all
combinations of flags expected to work? Else maybe we should instead
have a -T "test_name", or so, to keep them mutually exclusive and
easy to reason about.

Or just a test that two flags are not set at the same time.


^ permalink raw reply

* Re: [net-next v2 2/3] selftests/net: Test PACKET_STATISTICS drops
From: Willem de Bruijn @ 2026-04-04 15:08 UTC (permalink / raw)
  To: Joe Damato, netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, Simon Horman, Shuah Khan
  Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260403233240.178948-3-joe@dama.to>

Joe Damato wrote:
> Extend psock_snd to test drops by setting a tiny receive buffer and
> sending a large burst of packets.
> 
> Signed-off-by: Joe Damato <joe@dama.to>
> ---
>  tools/testing/selftests/net/psock_snd.c  | 48 ++++++++++++++++++++----
>  tools/testing/selftests/net/psock_snd.sh |  5 +++
>  2 files changed, 46 insertions(+), 7 deletions(-)
> 
> v2:
>   - Remove do_tx argument and use global cfg_drop instead
> 
> diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c
> index 5be481a3d2bd..81096df5cffc 100644
> --- a/tools/testing/selftests/net/psock_snd.c
> +++ b/tools/testing/selftests/net/psock_snd.c
> @@ -39,6 +39,7 @@ static bool	cfg_use_gso;
>  static bool	cfg_use_qdisc_bypass;
>  static bool	cfg_use_vlan;
>  static bool	cfg_use_vnet;
> +static bool	cfg_drop;
>  
>  static char	*cfg_ifname = "lo";
>  static int	cfg_mtu	= 1500;
> @@ -49,6 +50,8 @@ static uint16_t	cfg_port = 8000;
>  /* test sending up to max mtu + 1 */
>  #define TEST_SZ	(sizeof(struct virtio_net_hdr) + ETH_HLEN + ETH_MAX_MTU + 1)
>  
> +#define BURST_CNT (1000)
> +
>  static char tbuf[TEST_SZ], rbuf[TEST_SZ];
>  
>  static unsigned long add_csum_hword(const uint16_t *start, int num_u16)
> @@ -212,13 +215,14 @@ static void do_send(int fd, char *buf, int len)
>  	if (ret != len)
>  		error(1, 0, "write: %u %u", ret, len);
>  
> -	fprintf(stderr, "tx: %u\n", ret);
> +	if (!cfg_drop)
> +		fprintf(stderr, "tx: %u\n", ret);
>  }
>  
>  static int do_tx(void)
>  {
>  	const int one = 1;
> -	int fd, len;
> +	int i, fd, len;
>  
>  	fd = socket(PF_PACKET, cfg_use_dgram ? SOCK_DGRAM : SOCK_RAW, 0);
>  	if (fd == -1)
> @@ -242,6 +246,10 @@ static int do_tx(void)
>  
>  	do_send(fd, tbuf, len);
>  
> +	if (cfg_drop)
> +		for (i = 0; i < BURST_CNT; i++)
> +			do_send(fd, tbuf, len);
> +
>  	if (close(fd))
>  		error(1, errno, "close t");
>  
> @@ -290,6 +298,7 @@ static void do_rx(int fd, int expected_len, char *expected)
>  static int setup_sniffer(void)
>  {
>  	struct timeval tv = { .tv_usec = 100 * 1000 };
> +	const int one = 1;
>  	int fd;
>  
>  	fd = socket(PF_PACKET, SOCK_RAW, 0);
> @@ -299,6 +308,10 @@ static int setup_sniffer(void)
>  	if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)))
>  		error(1, errno, "setsockopt rcv timeout");
>  
> +	if (cfg_drop)
> +		if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &one, sizeof(one)))
> +			error(1, errno, "setsockopt SO_RCVBUF");
> +
>  	pair_udp_setfilter(fd);
>  	do_bind(fd);
>  
> @@ -309,7 +322,7 @@ static void parse_opts(int argc, char **argv)
>  {
>  	int c;
>  
> -	while ((c = getopt(argc, argv, "bcCdgl:qt:vV")) != -1) {
> +	while ((c = getopt(argc, argv, "bcCdDgl:qt:vV")) != -1) {
>  		switch (c) {
>  		case 'b':
>  			cfg_use_bind = true;
> @@ -323,6 +336,9 @@ static void parse_opts(int argc, char **argv)
>  		case 'd':
>  			cfg_use_dgram = true;
>  			break;
> +		case 'D':
> +			cfg_drop = true;
> +			break;
>  		case 'g':
>  			cfg_use_gso = true;
>  			break;
> @@ -367,11 +383,23 @@ static void check_packet_stats(int fd)
>  	if (getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &st, &len))
>  		error(1, errno, "getsockopt packet statistics");
>  
> -	if (st.tp_packets != 1)
> -		error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
> +	if (cfg_drop) {
> +		/* PACKET_STATISTICS reports all packets seen (including
> +		 * drops) in tp_packets
> +		 */
> +		if (st.tp_packets < st.tp_drops)
> +			error(1, 0, "stats: tp_packets %u < tp_drops %u",
> +			      st.tp_packets, st.tp_drops);
>  
> -	if (st.tp_drops != 0)
> -		error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
> +		if (st.tp_drops == 0)
> +			error(1, 0, "stats: expected drops but tp_drops == 0");
> +	} else {
> +		if (st.tp_packets != 1)
> +			error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
> +
> +		if (st.tp_drops != 0)
> +			error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
> +	}
>  
>  	/* verify clear on read */
>  	memset(&st, 0xff, sizeof(st));
> @@ -396,6 +424,11 @@ static void run_test(void)
>  
>  	total_len = do_tx();
>  
> +	if (cfg_drop) {
> +		check_packet_stats(fds);
> +		goto out;
> +	}

Sashiko pointed out that there may be a race here between rx
processing in the softirq and check_packet_stats. Seems plausible.

>  	/* BPF filter accepts only this length, vlan changes MAC */
>  	if (cfg_payload_len == DATA_LEN && !cfg_use_vlan) {
>  		do_rx(fds, total_len - sizeof(struct virtio_net_hdr),
> @@ -405,6 +438,7 @@ static void run_test(void)
>  
>  	do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
>  
> +out:
>  	if (close(fds))
>  		error(1, errno, "close s");
>  	if (close(fdr))
> diff --git a/tools/testing/selftests/net/psock_snd.sh b/tools/testing/selftests/net/psock_snd.sh
> index 1cbfeb5052ec..b6ef12fad5d5 100755
> --- a/tools/testing/selftests/net/psock_snd.sh
> +++ b/tools/testing/selftests/net/psock_snd.sh
> @@ -92,4 +92,9 @@ echo "raw gso max size"
>  echo "raw gso max size + 1 (expected to fail)"
>  (! ./in_netns.sh ./psock_snd -v -c -g -l "${max_mss_exceeds}")
>  
> +# test drops statistics
> +
> +echo "test drops statistics"
> +./in_netns.sh ./psock_snd -D
> +
>  echo "OK. All tests passed"
> -- 
> 2.52.0
> 



^ permalink raw reply

* [PATCH net-next v2 4/4] bpf-timestamp: complete tracing the skb from each push in sendmsg
From: Jason Xing @ 2026-04-04 15:04 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau
  Cc: netdev, bpf, Jason Xing
In-Reply-To: <20260404150452.83904-1-kerneljasonxing@gmail.com>

From: Jason Xing <kernelxing@tencent.com>

The patch is the 2/2 part of push-level granularity feature.

Prior to the patch, BPF timestamping cannot cover this case.
Here is how we reproduce in theory:
1) in the first round, __tcp_push_pending_frames() or tcp_push() kicks
   the stack to transfer the skb.
2) in the second round, problems like skb_copy_to_page_nocache() that
   returns with err code.
3) it jumps into 'do_error" label and then 'out' label.
4) at this point, there is no single skb staying in the write queue
5) the end of sendmsg

Monitor these two push functions with the previous one to complete
the conversion from send-level granularity to push-level granularity.

Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 net/ipv4/tcp.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 7d030a11d004..43fa8329a5ad 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1392,9 +1392,12 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
 
 		if (forced_push(tp)) {
 			tcp_mark_push(tp, skb);
+			tcp_bpf_tx_timestamp(sk);
 			__tcp_push_pending_frames(sk, mss_now, TCP_NAGLE_PUSH);
-		} else if (skb == tcp_send_head(sk))
+		} else if (skb == tcp_send_head(sk)) {
+			tcp_bpf_tx_timestamp(sk);
 			tcp_push_one(sk, mss_now);
+		}
 		continue;
 
 wait_for_space:
-- 
2.41.3


^ permalink raw reply related

* [PATCH net-next v2 3/4] bpf-timestamp: keep track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-04 15:04 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau
  Cc: netdev, bpf, Jason Xing, Yushan Zhou
In-Reply-To: <20260404150452.83904-1-kerneljasonxing@gmail.com>

From: Jason Xing <kernelxing@tencent.com>

The patch is the 1/2 part of push-level granularity feature.

Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
though it might not carry the last byte of the sendmsg.

Prior to the patch, BPF timestamping cannot cover this case:
The following steps reproduce this:
1) skb A is the current last skb before entering wait_for_space process
2) tcp_push() pushes A without any tag
3) A is transmitted from TCP to driver without putting any skb carrying
   timestamps in the error queue, like SCHED, DRV/HARDWARE.
4) sk_stream_wait_memory() sleeps for a while and then returns with an
   error code. Note that the socket lock is released.
5) skb A finally gets acked and removed from the rtx queue.
6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
   'do_error' label and then 'out' label.
7) at this moment, skb A turns out to be the last one in this send
   syscall, and miss the following tcp_bpf_tx_timestamp() opportunity
   before the final tcp_push()
8) BPF script fails to see any timestamps this time

Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 net/ipv4/tcp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index c603b90057f6..7d030a11d004 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1400,9 +1400,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
 wait_for_space:
 		set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
 		tcp_remove_empty_skb(sk);
-		if (copied)
+		if (copied) {
+			tcp_bpf_tx_timestamp(sk);
 			tcp_push(sk, flags & ~MSG_MORE, mss_now,
 				 TCP_NAGLE_PUSH, size_goal);
+		}
 
 		err = sk_stream_wait_memory(sk, &timeo);
 		if (err != 0)
-- 
2.41.3


^ permalink raw reply related

* [PATCH net-next v2 2/4] tcp: advance the tsflags check to save cycles
From: Jason Xing @ 2026-04-04 15:04 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, horms, willemb, martin.lau
  Cc: netdev, bpf, Jason Xing, Yushan Zhou
In-Reply-To: <20260404150452.83904-1-kerneljasonxing@gmail.com>

From: Jason Xing <kernelxing@tencent.com>

Check the tsflags first to see if the socket timestamping is enabled.
If so, then try to fetch the last skb from either write queue or
retransmission queue.

Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 net/ipv4/tcp.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 169c3fff4f6d..c603b90057f6 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -484,13 +484,14 @@ void tcp_init_sock(struct sock *sk)
 
 static void tcp_tx_timestamp(struct sock *sk, struct sockcm_cookie *sockc)
 {
-	struct sk_buff *skb = tcp_write_queue_tail(sk);
 	u32 tsflags = sockc->tsflags;
+	struct sk_buff *skb;
 
-	if (unlikely(!skb))
-		skb = skb_rb_last(&sk->tcp_rtx_queue);
+	if (!tsflags)
+		return;
 
-	if (tsflags && skb) {
+	skb = tcp_write_queue_tail(sk) ? : skb_rb_last(&sk->tcp_rtx_queue);
+	if (skb) {
 		struct skb_shared_info *shinfo = skb_shinfo(skb);
 		struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
 
-- 
2.41.3


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox