* Re: [Intel-wired-lan] [PATCH iwl-next v7 14/14] ixd: add devlink support
From: Larysa Zaremba @ 2026-04-28 14:13 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Fijalkowski, Maciej, Tantilov, Emil S, Chittim, Madhu,
Hay, Joshua A, Keller, Jacob E, Shanmugam, Jayaprakash,
Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Richard Cochran,
Kitszel, Przemyslaw, Andrew Lunn, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
R, Bharath
In-Reply-To: <IA3PR11MB8986407D74E9DE59F31B7AB5E5372@IA3PR11MB8986.namprd11.prod.outlook.com>
On Tue, Apr 28, 2026 at 10:53:47AM +0200, Loktionov, Aleksandr wrote:
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Larysa Zaremba
> > Sent: Tuesday, April 28, 2026 10:27 AM
> > To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>
> > Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> > Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> > <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> > <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> > <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> > <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> > Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> > <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> > <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> > David S. Miller <davem@davemloft.net>; Eric Dumazet
> > <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> > <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> > <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> > <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> > doc@vger.kernel.org; linux-kernel@vger.kernel.org; R, Bharath
> > <bharath.r@intel.com>
> > Subject: [Intel-wired-lan] [PATCH iwl-next v7 14/14] ixd: add devlink
> > support
> >
> > From: Amritha Nambiar <amritha.nambiar@intel.com>
> >
> > Enable initial support for the devlink interface with the ixd driver.
> > The ixd hardware is a single function PCIe device. So, the PCIe
> > adapter gets its own devlink instance to manage device-wide resources
> > or configuration.
> >
> > $ devlink dev show
> > pci/0000:83:00.6
> >
> > $ devlink dev info pci/0000:83:00.6
> > pci/0000:83:00.6:
> > driver ixd
> > serial_number 00-a0-c9-ff-ff-23-45-67
> > versions:
> > fixed:
> > device.type MEV
> > running:
> > virtchnl 2.0
> >
> > Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> > Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> > Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > Tested-by: Bharath R <Bharath.r@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > ---
> > Documentation/networking/devlink/index.rst | 1 +
> > Documentation/networking/devlink/ixd.rst | 30 ++++++
> > drivers/net/ethernet/intel/ixd/Kconfig | 1 +
> > drivers/net/ethernet/intel/ixd/Makefile | 1 +
> > drivers/net/ethernet/intel/ixd/ixd_devlink.c | 97
> > ++++++++++++++++++++ drivers/net/ethernet/intel/ixd/ixd_devlink.h |
> > 44 +++++++++
> > drivers/net/ethernet/intel/ixd/ixd_main.c | 16 +++-
> > 7 files changed, 187 insertions(+), 3 deletions(-) create mode
> > 100644 Documentation/networking/devlink/ixd.rst
> > create mode 100644 drivers/net/ethernet/intel/ixd/ixd_devlink.c
> > create mode 100644 drivers/net/ethernet/intel/ixd/ixd_devlink.h
> >
> > diff --git a/Documentation/networking/devlink/index.rst
> > b/Documentation/networking/devlink/index.rst
> > index f7ba7dcf477d..f0c077843fa7 100644
> > --- a/Documentation/networking/devlink/index.rst
> > +++ b/Documentation/networking/devlink/index.rst
> > @@ -88,6 +88,7 @@ parameters, info versions, and other features it
> > supports.
> > ionic
> > iosm
> > ixgbe
>
> ...
>
> > --- /dev/null
> > +++ b/drivers/net/ethernet/intel/ixd/ixd_devlink.h
> > @@ -0,0 +1,44 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright (c) 2025, Intel Corporation. */
> > +
> devlink.c has:
> > +// SPDX-License-Identifier: GPL-2.0
> But devlink.h has:
> > +/* SPDX-License-Identifier: GPL-2.0 */
>
> Why?
Because source and header files require different license format.
>
> > +#ifndef _IXD_DEVLINK_H_
> > +#define _IXD_DEVLINK_H_
> > +#include <net/devlink.h>
>
> ...
>
> > }
> >
> > static const struct pci_device_id ixd_pci_tbl[] = {
> > --
> > 2.47.0
>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v7 07/14] idpf: refactor idpf to use libie_pci APIs
From: Larysa Zaremba @ 2026-04-28 14:14 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Fijalkowski, Maciej, Tantilov, Emil S, Chittim, Madhu,
Hay, Joshua A, Keller, Jacob E, Shanmugam, Jayaprakash,
Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Richard Cochran,
Kitszel, Przemyslaw, Andrew Lunn, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Salin, Samuel
In-Reply-To: <IA3PR11MB898658952B56FC5666A64EE2E5372@IA3PR11MB8986.namprd11.prod.outlook.com>
On Tue, Apr 28, 2026 at 10:47:29AM +0200, Loktionov, Aleksandr wrote:
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Larysa Zaremba
> > Sent: Tuesday, April 28, 2026 10:27 AM
> > To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>
> > Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> > Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> > <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> > <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> > <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> > <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> > Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> > <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> > <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> > David S. Miller <davem@davemloft.net>; Eric Dumazet
> > <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> > <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> > <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> > <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> > doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> > <samuel.salin@intel.com>
> > Subject: [Intel-wired-lan] [PATCH iwl-next v7 07/14] idpf: refactor
> > idpf to use libie_pci APIs
> >
> > From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> >
> > Use libie_pci init and MMIO APIs where possible, struct idpf_hw cannot
> > be deleted for now as it also houses control queues that will be
> > refactored later. Use libie_cp header for libie_ctlq_ctx that contains
> > mmio info from the start in order to not increase the diff later.
> >
> > Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> > Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> > Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> > Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > Tested-by: Samuel Salin <Samuel.salin@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > ---
> > drivers/net/ethernet/intel/idpf/Kconfig | 1 +
> > drivers/net/ethernet/intel/idpf/idpf.h | 70 +-------
> > .../net/ethernet/intel/idpf/idpf_controlq.c | 26 ++-
> > .../net/ethernet/intel/idpf/idpf_controlq.h | 2 -
> > drivers/net/ethernet/intel/idpf/idpf_dev.c | 61 ++++---
> > drivers/net/ethernet/intel/idpf/idpf_idc.c | 38 ++--
> > drivers/net/ethernet/intel/idpf/idpf_lib.c | 7 +-
> > drivers/net/ethernet/intel/idpf/idpf_main.c | 114 ++++++------
> > drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 57 +++---
> > .../net/ethernet/intel/idpf/idpf_virtchnl.c | 169 +++++++++--------
> > -
> > .../ethernet/intel/idpf/idpf_virtchnl_ptp.c | 58 +++---
> > 11 files changed, 288 insertions(+), 315 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/Kconfig
> > b/drivers/net/ethernet/intel/idpf/Kconfig
> > index adab2154125b..586df3a4afe9 100644
> > --- a/drivers/net/ethernet/intel/idpf/Kconfig
> > +++ b/drivers/net/ethernet/intel/idpf/Kconfig
> > @@ -6,6 +6,7 @@ config IDPF
> > depends on PCI_MSI
> > depends on PTP_1588_CLOCK_OPTIONAL
> > select DIMLIB
> > + select LIBIE_CP
> > select LIBETH_XDP
> > help
> > This driver supports Intel(R) Infrastructure Data Path
> > Function diff --git a/drivers/net/ethernet/intel/idpf/idpf.h
> > b/drivers/net/ethernet/intel/idpf/idpf.h
> > index 0d08f51be7e3..efdb58990a8b 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf.h
> > +++ b/drivers/net/ethernet/intel/idpf/idpf.h
> > @@ -23,6 +23,7 @@ struct idpf_rss_data;
> >
> > #include <linux/intel/iidc_rdma.h>
> > #include <linux/intel/iidc_rdma_idpf.h>
> > +#include <linux/intel/libie/controlq.h>
> > #include <linux/intel/virtchnl2.h>
> >
> > #include "idpf_txrx.h"
> > @@ -625,6 +626,7 @@ struct idpf_vc_xn_manager;
> > * @flags: See enum idpf_flags
> > * @reset_reg: See struct idpf_reset_reg
> > * @hw: Device access data
>
> ...
>
> > for (i = 0; i < num_vecs; i++) {
> > struct idpf_q_vector *q_vector = &rsrc->q_vectors[i];
> > u16 vec_id = rsrc->q_vector_idxs[i] - IDPF_MBX_Q_VEC;
> > struct idpf_intr_reg *intr = &q_vector->intr_reg;
> > + struct idpf_vec_regs *reg = ®_vals[vec_id];
> > u32 spacing;
> >
> > - intr->dyn_ctl = idpf_get_reg_addr(adapter,
> > -
> > reg_vals[vec_id].dyn_ctl_reg);
> > + intr->dyn_ctl = libie_pci_get_mmio_addr(mmio,
> > + reg->dyn_ctl_reg);
> Stray TAB after =
Seems so.
>
> > intr->dyn_ctl_intena_m = PF_GLINT_DYN_CTL_INTENA_M;
> > intr->dyn_ctl_intena_msk_m =
> > PF_GLINT_DYN_CTL_INTENA_MSK_M;
> > intr->dyn_ctl_itridx_s = PF_GLINT_DYN_CTL_ITR_INDX_S; @@
>
> ...
>
> >
> > return 0;
> > }
> > --
> > 2.47.0
>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v7 07/14] idpf: refactor idpf to use libie_pci APIs
From: Larysa Zaremba @ 2026-04-28 14:16 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Fijalkowski, Maciej, Tantilov, Emil S, Chittim, Madhu,
Hay, Joshua A, Keller, Jacob E, Shanmugam, Jayaprakash,
Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Richard Cochran,
Kitszel, Przemyslaw, Andrew Lunn, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Salin, Samuel
In-Reply-To: <IA3PR11MB89866811B05E0CF99A6BA98CE5372@IA3PR11MB8986.namprd11.prod.outlook.com>
On Tue, Apr 28, 2026 at 11:00:22AM +0200, Loktionov, Aleksandr wrote:
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Larysa Zaremba
> > Sent: Tuesday, April 28, 2026 10:27 AM
> > To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>
> > Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> > Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> > <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> > <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> > <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> > <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> > Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> > <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> > <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> > David S. Miller <davem@davemloft.net>; Eric Dumazet
> > <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> > <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> > <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> > <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> > doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> > <samuel.salin@intel.com>
> > Subject: [Intel-wired-lan] [PATCH iwl-next v7 07/14] idpf: refactor
> > idpf to use libie_pci APIs
> >
> > From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> >
> > Use libie_pci init and MMIO APIs where possible, struct idpf_hw cannot
> > be deleted for now as it also houses control queues that will be
> > refactored later. Use libie_cp header for libie_ctlq_ctx that contains
> > mmio info from the start in order to not increase the diff later.
> >
> > Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> > Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> > Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> > Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > Tested-by: Samuel Salin <Samuel.salin@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > ---
> > drivers/net/ethernet/intel/idpf/Kconfig | 1 +
> > drivers/net/ethernet/intel/idpf/idpf.h | 70 +-------
> > .../net/ethernet/intel/idpf/idpf_controlq.c | 26 ++-
> > .../net/ethernet/intel/idpf/idpf_controlq.h | 2 -
> > drivers/net/ethernet/intel/idpf/idpf_dev.c | 61 ++++---
> > drivers/net/ethernet/intel/idpf/idpf_idc.c | 38 ++--
> > drivers/net/ethernet/intel/idpf/idpf_lib.c | 7 +-
> > drivers/net/ethernet/intel/idpf/idpf_main.c | 114 ++++++------
> > drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 57 +++---
> > .../net/ethernet/intel/idpf/idpf_virtchnl.c | 169 +++++++++--------
> > -
> > .../ethernet/intel/idpf/idpf_virtchnl_ptp.c | 58 +++---
> > 11 files changed, 288 insertions(+), 315 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/Kconfig
> > b/drivers/net/ethernet/intel/idpf/Kconfig
> > index adab2154125b..586df3a4afe9 100644
> > --- a/drivers/net/ethernet/intel/idpf/Kconfig
> > +++ b/drivers/net/ethernet/intel/idpf/Kconfig
> > @@ -6,6 +6,7 @@ config IDPF
> > depends on PCI_MSI
> > depends on PTP_1588_CLOCK_OPTIONAL
> > select DIMLIB
>
> ...
>
> > >dev_ops.static_reg_info;
> > + bool is_static = false;
> > +
> > + for (uint j = 0; j < IDPF_MMIO_REG_NUM_STATIC; j++)
> I think you need to use here unsigned int, didn't checkpach.pl complain about it?
No, it did not, and this is consistent with the similar regions loop in
drivers/net/ethernet/intel/idpf/idpf_idc.c.
>
>
> > + if (mr->offset == static_regs[j].start)
> > + is_static = true;
>
> ...
>
> >
> > return 0;
> > }
> > --
> > 2.47.0
>
^ permalink raw reply
* Re: [PATCH net 9/9] selftests/tc-testing: Add netem test case exercising loops
From: Victor Nogueira @ 2026-04-28 14:18 UTC (permalink / raw)
To: Paolo Abeni
Cc: Jamal Hadi Salim, netdev, davem, edumazet, kuba, horms, jiri,
stephen, savy, will, xmei5, pctammela, kuniyu, toke,
willemdebruijnkernel, hxzene
In-Reply-To: <850472d9-2dbb-446d-a070-0c2ee6b53cdf@redhat.com>
On Tue, Apr 28, 2026 at 7:16 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 4/26/26 9:09 PM, Jamal Hadi Salim wrote:
> > From: Victor Nogueira <victor@mojatatu.com>
> >
> > Add a netem nested duplicate test case to validate that it won't
> > cause an infinite loop
> >
> > Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
> > Acked-by: Stephen Hemminger <stephen@networkplumber.org>
> > Signed-off-by: Victor Nogueira <victor@mojatatu.com>
> > ---
> > .../tc-testing/tc-tests/qdiscs/netem.json | 33 ++++++++++++++++++-
> > 1 file changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json b/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json
> > index 3c4444961488..7c954989069d 100644
> > --- a/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json
> > +++ b/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json
> > @@ -336,5 +336,36 @@
> > "teardown": [
> > "$TC qdisc del dev $DUMMY handle 1: root"
> > ]
> > - }
> > + },
> > + {
> > + "id": "8c17",
> > + "name": "Test netem's recursive duplicate",
>
> This test is apparently consistently failing on our CI:
>
> # not ok 365 8c17 - Test netem's recursive duplicate
> # Value doesn't match: bytes: 294 != 196
> # Matching against output: {'kind': 'netem', 'handle': '1:', 'root':
> True, 'refcnt': 2, 'options': {'limit': 1, 'duplicate': {'duplicate': 1,
> 'correlation': 0}, 'seed': 17230427318941832146, 'ecn': False, 'gap':
> 0}, 'bytes': 196, 'packets': 2, 'drops': 1, 'overlimits': 0, 'requeues':
> 0, 'backlog': 0, 'qlen': 0}
>
> sample full info avail:
>
> https://github.com/p4tc-dev/tc-executor/blob/storage/artifacts/622604/1-tdc-sh/
It seems flaky; there was one run where it passed on the CI [1] and
is consistently passing locally. I think I know the reason for that, but will
investigate further to be sure and fix in v5. Thanks for bringing this up.
[1] https://github.com/p4tc-dev/tc-executor/blob/storage-dbg/artifacts/622277/1-tdc-sh/stdout#L1902
cheers,
Victor
^ permalink raw reply
* Re: [PATCH net-next v9 4/4] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
From: Simon Schippers @ 2026-04-28 14:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: willemdebruijn.kernel, jasowang, andrew+netdev, davem, edumazet,
kuba, pabeni, eperezma, leiyang, stephen, jon, tim.gebauer,
netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20260428100731-mutt-send-email-mst@kernel.org>
On 4/28/26 16:10, Michael S. Tsirkin wrote:
> On Tue, Apr 28, 2026 at 03:41:20PM +0200, Simon Schippers wrote:
>> On 4/28/26 15:22, Michael S. Tsirkin wrote:
>>> On Tue, Apr 28, 2026 at 03:10:44PM +0200, Simon Schippers wrote:
>>>> On 4/28/26 14:50, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 28, 2026 at 02:38:59PM +0200, Simon Schippers wrote:
>>>>>> This commit prevents tail-drop when a qdisc is present and the ptr_ring
>>>>>> becomes full. Once an entry is successfully produced and the ptr_ring
>>>>>> reaches capacity, the netdev queue is stopped instead of dropping
>>>>>> subsequent packets.
>>>>>>
>>>>>> If producing an entry fails anyways due to a race, tun_net_xmit returns
>>>>>> NETDEV_TX_BUSY, again avoiding a drop. Such races are expected because
>>>>>> LLTX is enabled and the transmit path operates without the usual locking.
>>>>>>
>>>>>> If no qdisc is present, the previous tail-drop behavior is preserved.
>>>>>>
>>>>>> The existing __tun_wake_queue() function of the consumer races with the
>>>>>> producer for waking/stopping the netdev queue: the consumer may drain
>>>>>> the ring just as the producer stops the queue, leading to a permanent
>>>>>> stall. To avoid this, the producer re-checks the ring after stopping
>>>>>> and wakes the queue itself if space was just made. An
>>>>>> smp_mb__after_atomic() is required so the re-peek of the ring sees any
>>>>>> drain that the consumer performed.
>>>>>> smp_mb__after_atomic() pairs with the test_and_clear_bit() inside of
>>>>>> netif_wake_subqueue():
>>>>>>
>>>>>> Consumer CPU Producer CPU
>>>>>> ======================== =========================
>>>>>> __ptr_ring_consume()
>>>>>> netif_wake_subqueue() netif_tx_stop_queue()
>>>>>> /\ smp_mb__after_atomic()
>>>>>> || __ptr_ring_produce_peek()
>>>>>> contains RMW operation
>>>>>> test_and_clear_bit()
>>>>>> /\
>>>>>> ||
>>>>>> "Fully ordered RMW:
>>>>>> smp_mb() before + after"
>>>>>> - atomic_t.txt
>>>>>>
>>>>>> Benchmarks:
>>>>>> The benchmarks show a slight regression in raw transmission performance,
>>>>>> though no packets are lost anymore.
>>>>>
>>>>> Could you include the packets received as well?
>>>>> To demonstrate the gains/lack of loss.
>>>>>
>>>>
>>>> Do you mean the number of packets received by the VM?
>>>> They should just be the same as the number sent (shown below), right?
>>>
>>> Minus the loss? Which this is about, right?
>>
>> Yes. I simply calculated "Lost/s":
>>
>> elapsed_time = 100e6 / sent_pps
>> Lost/s = total_errors / elapsed_time
>>
>>
>> To get back total_errors for example for TAP
>> 1 thread sending:
>>
>> elapsed_time = 100e6 / 1.136Mpps = 88s
>>
>> 3758 Mpps = total_errors / 88s
>> <=> total_errors = 331 million packets
>>
>> So, out of 431 million packets sent, 100 million were successfully
>> delivered and 331 million were lost.
>
> That is my issue.
>
> I kind of have trouble mapping that to the table below.
> For example:
>
> | TAP | Transmitted | 1.136 Mpps | 1.130 Mpps | -0.6% |
> | +-------------+--------------+----------------+----------+
> | | Lost/s | 3.758 Mpps | 0 pps | |
>
> how can # of lost packets exceed the # of transmitted packets?
>
> Thanks!
I just do use the sample script [1]:
./pktgen_sample02_multiqueue.sh -n 100000000 ...
... and this runs until 100_000_000 packets were sucessfully
transmitted, independently of the lost packets/errors.
[1] Link: https://www.kernel.org/doc/html/latest/networking/pktgen.html#sample-scripts
>
>
>>>
>>>> I assume they would be visible as RX-DRP for TAP.
>>>> For TAP + vhost-net I would have to rewrite the XDP drop
>>>> program to count the number of dropped packets...
>>>> And I would have to automate it...
>>>>
>>>>>>
>>>>>> The previously introduced threshold to only wake after the queue stopped
>>>>>> and half of the ring was consumed showed to be a descent choice:
>>>>>> Waking the queue whenever a consume made space in the ring strongly
>>>>>> degrades performance for tap, while waking only when the ring is empty
>>>>>> is too late and also hurts throughput for tap & tap+vhost-net.
>>>>>> Other ratios (3/4, 7/8) showed similar results (not shown here), so
>>>>>> 1/2 was chosen for the sake of simplicity for both tun/tap and
>>>>>> tun/tap+vhost-net.
>>>>>>
>>>>>> Test setup:
>>>>>> AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
>>>>>> Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2
>>>>>> mitigations disabled.
>>>>>>
>>>>>> Note for tap+vhost-net:
>>>>>> XDP drop program active in VM -> ~2.5x faster, slower for tap due to
>>>>>> more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)
>>>>>>
>>>>>> +--------------------------+--------------+----------------+----------+
>>>>>> | 1 thread | Stock | Patched with | diff |
>>>>>> | sending | | fq_codel qdisc | |
>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>> | TAP | Transmitted | 1.136 Mpps | 1.130 Mpps | -0.6% |
>>>>>> | +-------------+--------------+----------------+----------+
>>>>>> | | Lost/s | 3.758 Mpps | 0 pps | |
>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>> | TAP | Transmitted | 3.858 Mpps | 3.816 Mpps | -1.1% |
>>>>>> | +-------------+--------------+----------------+----------+
>>>>>> | +vhost-net | Lost/s | 789.8 Kpps | 0 pps | |
>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>
>>>>>> +--------------------------+--------------+----------------+----------+
>>>>>> | 2 threads | Stock | Patched with | diff |
>>>>>> | sending | | fq_codel qdisc | |
>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>> | TAP | Transmitted | 1.117 Mpps | 1.087 Mpps | -2.7% |
>>>>>> | +-------------+--------------+----------------+----------+
>>>>>> | | Lost/s | 8.476 Mpps | 0 pps | |
>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>> | TAP | Transmitted | 3.679 Mpps | 3.464 Mpps | -5.8% |
>>>>>> | +-------------+--------------+----------------+----------+
>>>>>> | +vhost-net | Lost/s | 5.306 Mpps | 0 pps | |
>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>
>>>>>> Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
>>>>>> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
>>>>>> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
>>>>>> ---
>>>>>> drivers/net/tun.c | 30 ++++++++++++++++++++++++++++--
>>>>>> 1 file changed, 28 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>>>> index efe809597622..c2a1618cc9db 100644
>>>>>> --- a/drivers/net/tun.c
>>>>>> +++ b/drivers/net/tun.c
>>>>>> @@ -1011,6 +1011,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>> struct netdev_queue *queue;
>>>>>> struct tun_file *tfile;
>>>>>> int len = skb->len;
>>>>>> + bool qdisc_present;
>>>>>> + int ret;
>>>>>>
>>>>>> rcu_read_lock();
>>>>>> tfile = rcu_dereference(tun->tfiles[txq]);
>>>>>> @@ -1065,13 +1067,37 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>>
>>>>>> nf_reset_ct(skb);
>>>>>>
>>>>>> - if (ptr_ring_produce(&tfile->tx_ring, skb)) {
>>>>>> + queue = netdev_get_tx_queue(dev, txq);
>>>>>> + qdisc_present = !qdisc_txq_has_no_queue(queue);
>>>>>> +
>>>>>> + spin_lock(&tfile->tx_ring.producer_lock);
>>>>>> + ret = __ptr_ring_produce(&tfile->tx_ring, skb);
>>>>>> + if (__ptr_ring_produce_peek(&tfile->tx_ring) && qdisc_present) {
>>>>>> + netif_tx_stop_queue(queue);
>>>>>> + /* Re-peek and wake if the consumer drained the ring
>>>>>> + * concurrently in a race. smp_mb__after_atomic() pairs
>>>>>> + * with the test_and_clear_bit() of netif_wake_subqueue()
>>>>>> + * in __tun_wake_queue().
>>>>>> + */
>>>>>> + smp_mb__after_atomic();
>>>>>> + if (!__ptr_ring_produce_peek(&tfile->tx_ring))
>>>>>> + netif_tx_wake_queue(queue);
>>>>>> + }
>>>>>> + spin_unlock(&tfile->tx_ring.producer_lock);
>>>>>> +
>>>>>> + if (ret) {
>>>>>> + /* If a qdisc is attached to our virtual device,
>>>>>> + * returning NETDEV_TX_BUSY is allowed.
>>>>>> + */
>>>>>> + if (qdisc_present) {
>>>>>> + rcu_read_unlock();
>>>>>> + return NETDEV_TX_BUSY;
>>>>>> + }
>>>>>> drop_reason = SKB_DROP_REASON_FULL_RING;
>>>>>> goto drop;
>>>>>> }
>>>>>>
>>>>>> /* dev->lltx requires to do our own update of trans_start */
>>>>>> - queue = netdev_get_tx_queue(dev, txq);
>>>>>> txq_trans_cond_update(queue);
>>>>>>
>>>>>> /* Notify and wake up reader process */
>>>>>> --
>>>>>> 2.43.0
>>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] devlink, mlx5: add init/fini ops for shared devlink
From: Jiri Pirko @ 2026-04-28 14:19 UTC (permalink / raw)
To: Przemek Kitszel
Cc: netdev, Jakub Kicinski, intel-wired-lan, Tony Nguyen,
Jacob Keller, Lukasz Czapnik, Jedrzej Jagielski, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Saeed Mahameed,
Leon Romanovsky, Tariq Toukan, Mark Bloch, Simon Horman,
Aleksandr Loktionov
In-Reply-To: <b94a55c7-3d86-47bf-8acc-b82e31766116@intel.com>
Tue, Apr 28, 2026 at 03:44:54PM +0200, przemyslaw.kitszel@intel.com wrote:
>On 4/28/26 13:10, Jiri Pirko wrote:
>> Tue, Apr 28, 2026 at 11:09:11AM +0200, przemyslaw.kitszel@intel.com wrote:
>> > Add .shd_init() and .shd_fini() ops, that will be called for the first
>> > devlink_shd_get() (to initialize driver' priv data) and on the last
>> > devlink_shd_put() (to allow for the cleanup). Both ops are optional.
>> >
>> > .shd_init() could return an error, which will stop creation of shd
>> > instance. The initializer also gets an additional, optional param,
>> > that driver could use for any needs.
>> >
>> > If any of the callbacks will need to get devlink instance, it could
>> > be accessed by shd_priv_to_devlink().
>> >
>> > Both callbacks are called with devl_lock held and devlink registered.
>> >
>> > Next commit will make use of the callbacks, another one will make use also
>> > of the non-null additional param (outside of this series).
>> >
>> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>> > Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>> > ---
>> > first discussed at:
>> > https://lore.kernel.org/netdev/20260325063143.261806-3-przemyslaw.kitszel@intel.com
>> >
>> > Sashiko suggested to convert devlink_shd_create() to return ERR_PTR(),
>> > and propagate that up to the driver. It think it will just make code more
>> > verbose for not much benefit. And drivers could just store err if they
>> > want in the passed @init_param.
>> >
>> > ---
>> > include/net/devlink.h | 26 +++++++++++++
>> > .../ethernet/mellanox/mlx5/core/sh_devlink.c | 2 +-
>> > net/devlink/sh_dev.c | 39 ++++++++++++++++++-
>> > 3 files changed, 64 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/include/net/devlink.h b/include/net/devlink.h
>> > index bcd31de1f890..5d3a1337bfa1 100644
>> > --- a/include/net/devlink.h
>> > +++ b/include/net/devlink.h
>> > @@ -1586,6 +1586,30 @@ struct devlink_ops {
>> > struct devlink_rate *parent,
>> > void *priv_child, void *priv_parent,
>> > struct netlink_ext_ack *extack);
>> > +
>> > + /**
>> > + * shd_init: Shared devlink instance initializer
>> > + * @priv: shd_devlink' priv
>> > + * @init_param: additional param to pass to driver callback
>> > + *
>> > + * Called once when the shared instance is first created (by the first
>> > + * devlink_shd_get() call).
>> > + * Should initialize the driver's private data embedded in the shared
>> > + * devlink. May be NULL.
>> > + *
>> > + * Return: 0 on success, negative to prevent shared instance usage.
>> > + */
>> > + int (*shd_init)(void *priv, void *init_param);
>>
>> 1. "param" has specific meaning in devlink context
>> 2. You don't use the arg in driver
>>
>> Care to drop it?
>
>I have a user for it, but it will be a separate series
>(I have already 15 patches there), will post RFC to link here
>to the user, will that work?
Add it when/if you need it, no? I still believe there might be a better
way instead of this.
>
>my intention was to not tie touching mlx code with big series for intel
>
>>
>> Otherwise, this looks fine to me. Thanks! (small nitpick below)
>
>ack for the nit
^ permalink raw reply
* Re: [PATCH 2/2] net: thunderbolt: enlarge RX/TX ring and set NAPI weight for sustained load
From: Mika Westerberg @ 2026-04-28 14:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Benjamin Berman, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <e6a249d5-8b11-43cf-89ee-14d436c70cf8@lunn.ch>
On Tue, Apr 28, 2026 at 02:54:58PM +0200, Andrew Lunn wrote:
> On Tue, Apr 28, 2026 at 09:42:53AM +0200, Mika Westerberg wrote:
> > On Mon, Apr 27, 2026 at 06:55:21PM -0700, Benjamin Berman wrote:
> > > The default TBNET_RING_SIZE of 256 and the NAPI_POLL_WEIGHT of 64
> > > implicit in netif_napi_add() are too small for host-to-host Thunderbolt
> > > networking under sustained bulk traffic. Running NCCL all-reduce over
> > > tb-lo on a three-node chain (two TB3 endpoints plus a TB4 Maple Ridge
> > > transit) produces rx_missed_errors at ~1 % of rx_packets on the transit
> > > and ~0.6 % on the endpoints, with rx_packets stalling against a peer's
> > > continuing tx_packets.
> > >
> > > Raise TBNET_RING_SIZE to 2048 (8x) and use netif_napi_add_weight() with
> > > a per-NAPI weight of 256 so tbnet_poll() drains more frames per softirq
> > > invocation. With matching sysctls (net.core.netdev_budget=1024,
> > > net.core.netdev_budget_usecs=8000) rx_missed_errors stays below 0.005 %
> > > over a 192 GB all-reduce workload on the same hardware.
> > >
> > > Generated-by: Claude Opus 4.7 <claude-opus-4-7@anthropic.com>
> > > Tested-by: Benjamin Berman <benjamin.s.berman@gmail.com>
> > > Signed-off-by: Benjamin Berman <benjamin.s.berman@gmail.com>
> >
> > For ring size I don't have any objections. The current ring size 256 is
> > arbitrary and at the time seemed reasonable.
> >
> > For the poll weigth there is the comment in netdevice.h:
> >
> > /* Default NAPI poll() weight
> > * Device drivers are strongly advised to not use bigger value
> > */
> > #define NAPI_POLL_WEIGHT 64
> >
> > But if you see improvement using 256 here I'm fine with that unless the
> > network folks advice otherwise.
>
> I just did a quick sample of other drivers which change the NAPI
> weight. Of the 10 i looked at, 9 reduced the weight. Only one
> increased it.
Yeah, I noticed it too. That's why asking for consultancy :)
> I would like the core netdev people to comment on this, before it is
> accepted.
>
> Questions which come to mind:
>
> Why is the polling not happening frequently enough?
>
> Is it frequently swapping between polling and interrupts?
>
> Is there interrupt coalesce going on, and the coalesce time set too
> high, so that by the time the interrupt fires the ring is full? Can
> you play with ethtool -C?
Thanks!
I'll leave these to Benjamin and Claude AI to answer.
One thing that could affect is the interrupt throttling that the hardware
is doing. We have quite big value there by default. Lowering that may have
affect as well. I just posted a patch series where one of the patches makes
this configurable in the tbnet driver so you could apply that and play with
the throttling value:
https://lore.kernel.org/linux-usb/20260428072209.3084930-6-mika.westerberg@linux.intel.com/
^ permalink raw reply
* Re: [PATCH v2 8/9] rtc: rv3032: switch to using FIELD_GET_SIGNED()
From: Alexandre Belloni @ 2026-04-28 14:20 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Jonathan Cameron,
David Lechner, Johannes Berg, David Laight, Nuno Sá,
Andy Shevchenko, Ping-Ke Shih, Richard Cochran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins, x86,
linux-kernel, linux-iio, linux-wireless, netdev, linux-rtc
In-Reply-To: <20260427214127.406067-9-ynorov@nvidia.com>
On 27/04/2026 17:41:25-0400, Yury Norov wrote:
> Switch from sign_extend32(FIELD_GET()) to the dedicated
> FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/rtc/rtc-rv3032.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-rv3032.c b/drivers/rtc/rtc-rv3032.c
> index 6c09da7738e1..6bafdec637ae 100644
> --- a/drivers/rtc/rtc-rv3032.c
> +++ b/drivers/rtc/rtc-rv3032.c
> @@ -376,7 +376,7 @@ static int rv3032_read_offset(struct device *dev, long *offset)
> if (ret < 0)
> return ret;
>
> - steps = sign_extend32(FIELD_GET(RV3032_OFFSET_MSK, value), 5);
> + steps = FIELD_GET_SIGNED(RV3032_OFFSET_MSK, value);
>
> *offset = DIV_ROUND_CLOSEST(steps * OFFSET_STEP_PPT, 1000);
>
> --
> 2.51.0
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 0/9] Support for block device NVMEM providers
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
On embedded devices, it is common for factory provisioning to store
device-specific information, such as Ethernet or WiFi MAC addresses,
in a dedicated area of an eMMC partition. This avoids the need for
and additional EEPROM/OTP and leverages the persistence of eMMC.
One example is the Arduino UNO-Q, where the WiFi MAC address and the
Bluetooth Device address are stored in the eMMC Boot1 partition.
Until now, accessing this information required a custom bootloader
to read the data and inject it into the Device Tree before handing
control over to the kernel. This approach is fragile and leads to
device-specific workarounds.
Rather than adding a new NVMEM provider specifically to the eMMC
subsystem, the new support operates at the block layer, allowing any
block device to behave like other non-volatile memories such as EEPROM
or OTP.
This series builds on earlier work by Daniel Golle that enables block
devices to act as NVMEM providers:
https://lore.kernel.org/all/6061aa4201030b9bb2f8d03ef32a564fdb786ed1.1709667858.git.daniel@makrotopia.org/
It also introduces an NVMEM layout description for the Arduino UNO-Q,
allowing device-specific data stored in the eMMC Boot1 partition to
be accessed in a standard way.
WiFi and Ethernet already support retrieving MAC addresses from NVMEM.
Bluetooth requires similar support, which is also addressed.
Note that this is currently limited to eMMC-backed block devices, as
only the eMMC core associates a firmware node with the block device
(add_disk_fwnode). This can be easily extended in the future to
support additional block drivers.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Daniel Golle (1):
block: implement NVMEM provider
Loic Poulain (8):
dt-bindings: mmc: Document support for nvmem-layout
arm64: dts: qcom: arduino-imola: Describe boot1 NVMEM layout
dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
arm64: dts: qcom: arduino-imola: Get WiFi MAC from NVMEM
dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
arm64: dts: qcom: arduino-imola: Get Bluetooth BD address from NVMEM
.../devicetree/bindings/mmc/mmc-card.yaml | 20 +++
.../net/bluetooth/qcom,bluetooth-common.yaml | 10 ++
.../bindings/net/wireless/qcom,ath10k.yaml | 10 ++
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 30 ++++
block/Kconfig | 9 ++
block/Makefile | 1 +
block/blk-nvmem.c | 164 +++++++++++++++++++++
drivers/bluetooth/btqca.c | 5 +-
include/net/bluetooth/hci.h | 18 +++
net/bluetooth/hci_sync.c | 56 ++++++-
10 files changed, 321 insertions(+), 2 deletions(-)
---
base-commit: 47c4835fc0fed583d01d90387b67633950eba2b2
change-id: 20260428-block-as-nvmem-4b308e8bda9a
Best regards,
--
Loic Poulain <loic.poulain@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/9] dt-bindings: mmc: Document support for nvmem-layout
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
Add support for an nvmem-layout subnode under an eMMC hardware
partition. This allows the partition to be exposed as an NVMEM
provider and its internal layout to be described. For example,
an eMMC boot partition can be used to store device-specific
information such as a WiFi MAC address.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
Documentation/devicetree/bindings/mmc/mmc-card.yaml | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index a61d6c96df759102f9c1fbfd548b026a77921cae..e01fc82ab8520a31196475b18acb5e839e1bf71f 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -40,6 +40,9 @@ patternProperties:
contains:
const: fixed-partitions
+ nvmem-layout:
+ $ref: /schemas/nvmem/layouts/nvmem-layout.yaml
+
required:
- compatible
- reg
@@ -86,6 +89,23 @@ examples:
read-only;
};
};
+
+ partitions-boot2 {
+ nvmem-layout {
+ compatible = "fixed-layout";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ mac-addr@4400 {
+ reg = <0x4400 0x6>;
+ };
+
+ bd-addr@5400 {
+ reg = <0x5400 0x6>;
+ };
+ };
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/9] arm64: dts: qcom: arduino-imola: Describe boot1 NVMEM layout
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
On Arduino Uno-Q, the eMMC boot1 partition is factory provisioned
with device-specific information such as the WiFi MAC address
and the Bluetooth BD address. This partition can serve as an
alternative to additional non-volatile memory, such as a
dedicated EEPROM.
The eMMC boot partitions are typically good candidates, as they
are realively small, read-only by default (and can be enforced
as hardware read-only), and are not affected by board reflashing
procedures, which generally target the eMMC user or GP partitions.
Describe the corresponding nvmem-layout for the WiFi and
Bluetooth addresses.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
index bf088fa9807f040f0c8f405f9111b01790b09377..dc85cf94f71cac8666cab30ccf37cc2d2f8fd941 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
@@ -409,7 +409,31 @@ &sdhc_1 {
no-sdio;
no-sd;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
status = "okay";
+
+ card@0 {
+ compatible = "mmc-card";
+ reg = <0>;
+
+ partitions-boot1 {
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ wifi_mac_addr: mac-addr@4400 {
+ reg = <0x4400 0x6>;
+ };
+
+ bd_addr: bd-addr@5400 {
+ reg = <0x5400 0x6>;
+ };
+ };
+ };
+ };
};
&spi5 {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/9] block: implement NVMEM provider
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
From: Daniel Golle <daniel@makrotopia.org>
On embedded devices using an eMMC it is common that one or more partitions
on the eMMC are used to store MAC addresses and Wi-Fi calibration EEPROM
data. Allow referencing the partition in device tree for the kernel and
Wi-Fi drivers accessing it via the NVMEM layer.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
block/Kconfig | 9 +++
block/Makefile | 1 +
block/blk-nvmem.c | 164 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 174 insertions(+)
diff --git a/block/Kconfig b/block/Kconfig
index 15027963472d7b40e27b9097a5993c457b5b3054..0b33747e16dc33473683706f75c92bdf8b648f7c 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -209,6 +209,15 @@ config BLK_INLINE_ENCRYPTION_FALLBACK
by falling back to the kernel crypto API when inline
encryption hardware is not present.
+config BLK_NVMEM
+ bool "Block device NVMEM provider"
+ depends on OF
+ depends on NVMEM
+ help
+ Allow block devices (or partitions) to act as NVMEM providers,
+ typically used with eMMC to store MAC addresses or Wi-Fi
+ calibration data on embedded devices.
+
source "block/partitions/Kconfig"
config BLK_PM
diff --git a/block/Makefile b/block/Makefile
index 7dce2e44276c4274c11a0a61121c83d9c43d6e0c..d7ac389e71902bc091a8800ea266190a43b3e63d 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_BLK_INLINE_ENCRYPTION) += blk-crypto.o blk-crypto-profile.o \
blk-crypto-sysfs.o
obj-$(CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK) += blk-crypto-fallback.o
obj-$(CONFIG_BLOCK_HOLDER_DEPRECATED) += holder.o
+obj-$(CONFIG_BLK_NVMEM) += blk-nvmem.o
diff --git a/block/blk-nvmem.c b/block/blk-nvmem.c
new file mode 100644
index 0000000000000000000000000000000000000000..01b67c638a6dfd1393043024b6a7f3ebb947a57c
--- /dev/null
+++ b/block/blk-nvmem.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * block device NVMEM provider
+ *
+ * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
+ *
+ * Useful on devices using a partition on an eMMC for MAC addresses or
+ * Wi-Fi calibration EEPROM data.
+ */
+
+#include "blk.h"
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/pagemap.h>
+#include <linux/property.h>
+
+/* List of all NVMEM devices */
+static LIST_HEAD(nvmem_devices);
+static DEFINE_MUTEX(devices_mutex);
+
+struct blk_nvmem {
+ struct nvmem_device *nvmem;
+ struct device *dev;
+ struct list_head list;
+};
+
+static int blk_nvmem_reg_read(void *priv, unsigned int from,
+ void *val, size_t bytes)
+{
+ blk_mode_t mode = BLK_OPEN_READ | BLK_OPEN_RESTRICT_WRITES;
+ unsigned long offs = from & ~PAGE_MASK, to_read;
+ pgoff_t f_index = from >> PAGE_SHIFT;
+ struct blk_nvmem *bnv = priv;
+ size_t bytes_left = bytes;
+ struct file *bdev_file;
+ struct folio *folio;
+ void *p;
+ int ret = 0;
+
+ bdev_file = bdev_file_open_by_dev(bnv->dev->devt, mode, priv, NULL);
+ if (!bdev_file)
+ return -ENODEV;
+
+ if (IS_ERR(bdev_file))
+ return PTR_ERR(bdev_file);
+
+ while (bytes_left) {
+ folio = read_mapping_folio(bdev_file->f_mapping, f_index++, NULL);
+ if (IS_ERR(folio)) {
+ ret = PTR_ERR(folio);
+ goto err_release_bdev;
+ }
+ to_read = min_t(unsigned long, bytes_left, PAGE_SIZE - offs);
+ p = folio_address(folio) + offset_in_folio(folio, offs);
+ memcpy(val, p, to_read);
+ offs = 0;
+ bytes_left -= to_read;
+ val += to_read;
+ folio_put(folio);
+ }
+
+err_release_bdev:
+ fput(bdev_file);
+
+ return ret;
+}
+
+static int blk_nvmem_register(struct device *dev)
+{
+ struct device_node *np = dev_of_node(dev);
+ struct block_device *bdev = dev_to_bdev(dev);
+ struct nvmem_config config = {};
+ struct blk_nvmem *bnv;
+
+ /* skip devices which do not have a device tree node */
+ if (!np)
+ return 0;
+
+ /* skip devices without an nvmem layout defined */
+ if (!of_get_child_by_name(np, "nvmem-layout"))
+ return 0;
+
+ /*
+ * skip block device too large to be represented as NVMEM devices
+ * which are using an 'int' as address
+ */
+ if (bdev_nr_bytes(bdev) > INT_MAX)
+ return -EFBIG;
+
+ bnv = kzalloc_obj(*bnv);
+ if (!bnv)
+ return -ENOMEM;
+
+ config.id = NVMEM_DEVID_NONE;
+ config.dev = &bdev->bd_device;
+ config.name = dev_name(&bdev->bd_device);
+ config.owner = THIS_MODULE;
+ config.priv = bnv;
+ config.reg_read = blk_nvmem_reg_read;
+ config.size = bdev_nr_bytes(bdev);
+ config.word_size = 1;
+ config.stride = 1;
+ config.read_only = true;
+ config.root_only = true;
+ config.ignore_wp = true;
+ config.of_node = to_of_node(dev->fwnode);
+
+ bnv->dev = &bdev->bd_device;
+ bnv->nvmem = nvmem_register(&config);
+ if (IS_ERR(bnv->nvmem)) {
+ dev_err_probe(&bdev->bd_device, PTR_ERR(bnv->nvmem),
+ "Failed to register NVMEM device\n");
+
+ kfree(bnv);
+ return PTR_ERR(bnv->nvmem);
+ }
+
+ mutex_lock(&devices_mutex);
+ list_add_tail(&bnv->list, &nvmem_devices);
+ mutex_unlock(&devices_mutex);
+
+ return 0;
+}
+
+static void blk_nvmem_unregister(struct device *dev)
+{
+ struct blk_nvmem *bnv_c, *bnv = NULL;
+
+ mutex_lock(&devices_mutex);
+ list_for_each_entry(bnv_c, &nvmem_devices, list) {
+ if (bnv_c->dev == dev) {
+ bnv = bnv_c;
+ break;
+ }
+ }
+
+ if (!bnv) {
+ mutex_unlock(&devices_mutex);
+ return;
+ }
+
+ list_del(&bnv->list);
+ mutex_unlock(&devices_mutex);
+ nvmem_unregister(bnv->nvmem);
+ kfree(bnv);
+}
+
+static struct class_interface blk_nvmem_bus_interface __refdata = {
+ .class = &block_class,
+ .add_dev = &blk_nvmem_register,
+ .remove_dev = &blk_nvmem_unregister,
+};
+
+static int __init blk_nvmem_init(void)
+{
+ int ret;
+
+ ret = class_interface_register(&blk_nvmem_bus_interface);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+device_initcall(blk_nvmem_init);
--
2.34.1
^ permalink raw reply related
* [PATCH 4/9] dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
Add support for an NVMEM cell provider with the standard "mac-address"
cell name. This allows the ath10k device to retrieve its MAC address
from non-volatile storage such as an EEPROM or an eMMC partition.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index c21d66c7cd558ab792524be9afec8b79272d1c87..7155d8b15cc145c3a7d703db0c9c3e056a54c07e 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -92,6 +92,16 @@ properties:
ieee80211-freq-limit: true
+ nvmem-cells:
+ maxItems: 1
+ description:
+ Nvmem data cell that contains a 6 byte MAC address with the most
+ significant byte first (big-endian).
+
+ nvmem-cell-names:
+ items:
+ - const: mac-address
+
qcom,calibration-data:
$ref: /schemas/types.yaml#/definitions/uint8-array
description:
--
2.34.1
^ permalink raw reply related
* [PATCH 5/9] arm64: dts: qcom: arduino-imola: Get WiFi MAC from NVMEM
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
On Arduino Uno-Q, the WiFi MAC address is stored in the eMMC
boot1 partition. Point to the appropriate NVMEM cell to
retrieve it.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
index dc85cf94f71cac8666cab30ccf37cc2d2f8fd941..35a30cd6f47d6d2e018f6841a05fe929fec15738 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
@@ -581,6 +581,9 @@ &wifi {
qcom,ath10k-calibration-variant = "ArduinoImola";
firmware-name = "qcm2290";
+ nvmem-cells = <&wifi_mac_addr>;
+ nvmem-cell-names = "mac-address";
+
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 6/9] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
Add support for an NVMEM cell provider for "local-bd-address",
allowing the Bluetooth stack to retrieve controller's BD address
from non-volatile storage such as an EEPROM or an eMMC partition.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
.../bindings/net/bluetooth/qcom,bluetooth-common.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
index c8e9c55c1afb4c8e05ba2dae41ce2db4194b4a0f..ecb3de65506f7f0f1fc1d0b9bbd316163b7c26e8 100644
--- a/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
+++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,bluetooth-common.yaml
@@ -22,4 +22,14 @@ properties:
description:
boot firmware is incorrectly passing the address in big-endian order
+ nvmem-cells:
+ maxItems: 1
+ description:
+ Nvmem data cell that contains a 6 byte BD address with the most
+ significant byte first (big-endian).
+
+ nvmem-cell-names:
+ items:
+ - const: local-bd-address
+
additionalProperties: true
--
2.34.1
^ permalink raw reply related
* [PATCH 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
Some devices store the Bluetooth BD address in non-volatile
memory, which can be accessed through the NVMEM framework.
Similar to Ethernet or WiFi MAC addresses, add support for
reading the BD address from a 'local-bd-address' NVMEM cell.
As with the device-tree provided BD address, add a quirk to
indicate whether a device or platform should attempt to read
the address from NVMEM when no valid in-chip address is present.
Also add a quirk to indicate if the address is stored in
big-endian byte order.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
include/net/bluetooth/hci.h | 18 +++++++++++++++
net/bluetooth/hci_sync.c | 56 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 572b1c620c5d653a1fe10b26c1b0ba33e8f4968f..7686466d1109253b0d75edeb5f6a99fb98ce4cc6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -164,6 +164,24 @@ enum {
*/
HCI_QUIRK_BDADDR_PROPERTY_BROKEN,
+ /* When this quirk is set, the public Bluetooth address
+ * initially reported by HCI Read BD Address command
+ * is considered invalid. The public BD Address can be
+ * retrieved via a 'local-bd-address' NVMEM cell.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_USE_BDADDR_NVMEM,
+
+ /* When this quirk is set, the Bluetooth Device Address provided by
+ * the 'local-bd-address' NVMEM is stored in big-endian order.
+ *
+ * This quirk can be set before hci_register_dev is called or
+ * during the hdev->setup vendor callback.
+ */
+ HCI_QUIRK_BDADDR_NVMEM_BE,
+
/* When this quirk is set, the duplicate filtering during
* scanning is based on Bluetooth devices addresses. To allow
* RSSI based updates, restart scanning if needed.
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index fd3aacdea512a37c22b9a2be90c89ddca4b4d99f..f87cb6ae85c3a5754fe79f415ba05dd177f75fad 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -6,6 +6,7 @@
* Copyright 2023 NXP
*/
+#include <linux/nvmem-consumer.h>
#include <linux/property.h>
#include <net/bluetooth/bluetooth.h>
@@ -3588,6 +3589,54 @@ int hci_powered_update_sync(struct hci_dev *hdev)
return 0;
}
+/**
+ * hci_dev_get_bd_addr_from_nvmem - Get the Bluetooth Device Address
+ * (BD_ADDR) for a HCI device from
+ * an NVMEM cell.
+ * @hdev: The HCI device
+ *
+ * Search for 'local-bd-address' NVMEM cell.
+ *
+ * All-zero BD addresses are rejected (unprovisioned).
+ */
+static int hci_dev_get_bd_addr_from_nvmem(struct hci_dev *hdev)
+{
+ struct device *dev = hdev->dev.parent;
+ struct nvmem_cell *cell;
+ const void *ba;
+ int err = 0;
+ size_t len;
+
+ cell = nvmem_cell_get(dev, "local-bd-address");
+ if (IS_ERR(cell))
+ return PTR_ERR(cell);
+
+ ba = nvmem_cell_read(cell, &len);
+ nvmem_cell_put(cell);
+
+ if (IS_ERR(ba)) {
+ bt_dev_warn(hdev, "Error reading BD address from NVMEM (%ld)\n",
+ PTR_ERR(ba));
+ err = PTR_ERR(ba);
+ goto done;
+ }
+
+ if (len != sizeof(bdaddr_t) || !bacmp(ba, BDADDR_ANY)) {
+ bt_dev_warn(hdev, "NVMEM BD address has incorrect format\n");
+ err = -EINVAL;
+ goto done;
+ }
+
+ if (hci_test_quirk(hdev, HCI_QUIRK_BDADDR_NVMEM_BE))
+ baswap(&hdev->public_addr, (bdaddr_t *)ba);
+ else
+ bacpy(&hdev->public_addr, (bdaddr_t *)ba);
+
+done:
+ kfree(ba);
+ return err;
+}
+
/**
* hci_dev_get_bd_addr_from_property - Get the Bluetooth Device Address
* (BD_ADDR) for a HCI device from
@@ -5042,12 +5091,17 @@ static int hci_dev_setup_sync(struct hci_dev *hdev)
* its setup callback.
*/
invalid_bdaddr = hci_test_quirk(hdev, HCI_QUIRK_INVALID_BDADDR) ||
- hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
+ hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY) ||
+ hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM);
if (!ret) {
if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY) &&
!bacmp(&hdev->public_addr, BDADDR_ANY))
hci_dev_get_bd_addr_from_property(hdev);
+ if (hci_test_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM) &&
+ !bacmp(&hdev->public_addr, BDADDR_ANY))
+ hci_dev_get_bd_addr_from_nvmem(hdev);
+
if (invalid_bdaddr && bacmp(&hdev->public_addr, BDADDR_ANY) &&
hdev->set_bdaddr) {
ret = hdev->set_bdaddr(hdev, &hdev->public_addr);
--
2.34.1
^ permalink raw reply related
* [PATCH 8/9] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
When the controller BD address is invalid (zero or default),
set the NVMEM quirks to allow retrieving the address from a
'local-bd-address' NVMEM cell. The BD address is often stored
alongside the WiFi MAC address in big-endian format, so also
set the big-endian quirk.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
drivers/bluetooth/btqca.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index dda76365726f0bfe0e80e05fe04859fa4f0592e1..df33eacfd29fa680f393f90215150743e6001d5b 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -721,8 +721,11 @@ static int qca_check_bdaddr(struct hci_dev *hdev, const struct qca_fw_config *co
}
bda = (struct hci_rp_read_bd_addr *)skb->data;
- if (!bacmp(&bda->bdaddr, &config->bdaddr))
+ if (!bacmp(&bda->bdaddr, &config->bdaddr)) {
hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_PROPERTY);
+ hci_set_quirk(hdev, HCI_QUIRK_USE_BDADDR_NVMEM);
+ hci_set_quirk(hdev, HCI_QUIRK_BDADDR_NVMEM_BE);
+ }
kfree_skb(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH 9/9] arm64: dts: qcom: arduino-imola: Get Bluetooth BD address from NVMEM
From: Loic Poulain @ 2026-04-28 14:23 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel,
Loic Poulain
In-Reply-To: <20260428-block-as-nvmem-v1-0-6ad23e75190a@oss.qualcomm.com>
On Arduino Uno-Q, the Bluetooth Device address is stored in the eMMC
boot1 partition. Point to the appropriate NVMEM cell to retrieve it.
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
index 35a30cd6f47d6d2e018f6841a05fe929fec15738..109fa76e05625461935e321e15dbfe6c7d452e78 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
@@ -536,6 +536,9 @@ bluetooth {
vddch0-supply = <&pm4125_l22>;
enable-gpios = <&tlmm 87 GPIO_ACTIVE_HIGH>;
max-speed = <3000000>;
+
+ nvmem-cells = <&bd_addr>;
+ nvmem-cell-names = "local-bd-address";
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH net] MAINTAINERS: Add myself as NFC subsystem maintainer
From: David Heidelberg via B4 Relay @ 2026-04-28 14:24 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: linux-kernel, netdev, oe-linux-nfc, David Heidelberg
From: David Heidelberg <david@ixit.cz>
Add myself and update the mailing list.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
MAINTAINERS | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 21288a3a7d930..176390ef4275d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18824,18 +18824,20 @@ M: David Ahern <dsahern@kernel.org>
L: netdev@vger.kernel.org
S: Maintained
F: include/net/netns/nexthop.h
F: include/net/nexthop.h
F: include/uapi/linux/nexthop.h
F: net/ipv4/nexthop.c
NFC SUBSYSTEM
-L: netdev@vger.kernel.org
-S: Orphan
+M: David Heidelberg <david+nfc@ixit.cz>
+L: oe-linux-nfc@lists.linux.dev
+S: Maintained
+T: git https://codeberg.org/linux-nfc/linux.git
F: Documentation/devicetree/bindings/net/nfc/
F: drivers/nfc/
F: include/net/nfc/
F: include/uapi/linux/nfc.h
F: net/nfc/
NFC VIRTUAL NCI DEVICE DRIVER
M: Bongsu Jeon <bongsu.jeon@samsung.com>
---
base-commit: 46f74a3f7d57d9cc0110b09cbc8163fa0a01afa2
change-id: 20260428-nfc-maintainer-2b8e073907cd
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply related
* Re: [PATCH net] net: airoha: Move entries to queue head in case of DMA mapping failure in airoha_dev_xmit()
From: Lorenzo Bianconi @ 2026-04-28 14:27 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Jacob Keller, Simon Horman, linux-arm-kernel, linux-mediatek,
netdev
In-Reply-To: <679ebe0a-5889-4a84-afd6-3da50a07bced@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
> On 4/28/26 10:44 AM, Lorenzo Bianconi wrote:
> > In order to respect the original descriptor order and avoid any
> > potential IOMMU fault or memory corruption, move pending queue entries
> > to the head of hw queue tx_list if the DMA mapping of current inflight
> > packet fails in airoha_dev_xmit routine.
> >
> > Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > drivers/net/ethernet/airoha/airoha_eth.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index 5effb4a4ae84..82018a085e46 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> > @@ -2123,14 +2123,14 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> > return NETDEV_TX_OK;
> >
> > error_unmap:
> > - while (!list_empty(&tx_list)) {
> > + list_for_each_entry(e, &tx_list, list) {
> > e = list_first_entry(&tx_list, struct airoha_queue_entry,
> > list);
>
> Coccinelle says:
>
> +/srv/nipa-builds-contest/testing/wt-cocci/drivers/net/ethernet/airoha/airoha_eth.c:2123:1-20:
> iterator with update on line 2124
>
> I guess you should additionally drop the statement above.
ack, sorry. I will fix it in v2.
Regards,
Lorenzo
>
> /P
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v9 4/4] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
From: Michael S. Tsirkin @ 2026-04-28 14:32 UTC (permalink / raw)
To: Simon Schippers
Cc: willemdebruijn.kernel, jasowang, andrew+netdev, davem, edumazet,
kuba, pabeni, eperezma, leiyang, stephen, jon, tim.gebauer,
netdev, linux-kernel, kvm, virtualization
In-Reply-To: <f4274173-23ef-43c3-aab4-b64678b440ec@tu-dortmund.de>
On Tue, Apr 28, 2026 at 04:18:54PM +0200, Simon Schippers wrote:
> On 4/28/26 16:10, Michael S. Tsirkin wrote:
> > On Tue, Apr 28, 2026 at 03:41:20PM +0200, Simon Schippers wrote:
> >> On 4/28/26 15:22, Michael S. Tsirkin wrote:
> >>> On Tue, Apr 28, 2026 at 03:10:44PM +0200, Simon Schippers wrote:
> >>>> On 4/28/26 14:50, Michael S. Tsirkin wrote:
> >>>>> On Tue, Apr 28, 2026 at 02:38:59PM +0200, Simon Schippers wrote:
> >>>>>> This commit prevents tail-drop when a qdisc is present and the ptr_ring
> >>>>>> becomes full. Once an entry is successfully produced and the ptr_ring
> >>>>>> reaches capacity, the netdev queue is stopped instead of dropping
> >>>>>> subsequent packets.
> >>>>>>
> >>>>>> If producing an entry fails anyways due to a race, tun_net_xmit returns
> >>>>>> NETDEV_TX_BUSY, again avoiding a drop. Such races are expected because
> >>>>>> LLTX is enabled and the transmit path operates without the usual locking.
> >>>>>>
> >>>>>> If no qdisc is present, the previous tail-drop behavior is preserved.
> >>>>>>
> >>>>>> The existing __tun_wake_queue() function of the consumer races with the
> >>>>>> producer for waking/stopping the netdev queue: the consumer may drain
> >>>>>> the ring just as the producer stops the queue, leading to a permanent
> >>>>>> stall. To avoid this, the producer re-checks the ring after stopping
> >>>>>> and wakes the queue itself if space was just made. An
> >>>>>> smp_mb__after_atomic() is required so the re-peek of the ring sees any
> >>>>>> drain that the consumer performed.
> >>>>>> smp_mb__after_atomic() pairs with the test_and_clear_bit() inside of
> >>>>>> netif_wake_subqueue():
> >>>>>>
> >>>>>> Consumer CPU Producer CPU
> >>>>>> ======================== =========================
> >>>>>> __ptr_ring_consume()
> >>>>>> netif_wake_subqueue() netif_tx_stop_queue()
> >>>>>> /\ smp_mb__after_atomic()
> >>>>>> || __ptr_ring_produce_peek()
> >>>>>> contains RMW operation
> >>>>>> test_and_clear_bit()
> >>>>>> /\
> >>>>>> ||
> >>>>>> "Fully ordered RMW:
> >>>>>> smp_mb() before + after"
> >>>>>> - atomic_t.txt
> >>>>>>
> >>>>>> Benchmarks:
> >>>>>> The benchmarks show a slight regression in raw transmission performance,
> >>>>>> though no packets are lost anymore.
> >>>>>
> >>>>> Could you include the packets received as well?
> >>>>> To demonstrate the gains/lack of loss.
> >>>>>
> >>>>
> >>>> Do you mean the number of packets received by the VM?
> >>>> They should just be the same as the number sent (shown below), right?
> >>>
> >>> Minus the loss? Which this is about, right?
> >>
> >> Yes. I simply calculated "Lost/s":
> >>
> >> elapsed_time = 100e6 / sent_pps
> >> Lost/s = total_errors / elapsed_time
> >>
> >>
> >> To get back total_errors for example for TAP
> >> 1 thread sending:
> >>
> >> elapsed_time = 100e6 / 1.136Mpps = 88s
> >>
> >> 3758 Mpps = total_errors / 88s
> >> <=> total_errors = 331 million packets
> >>
> >> So, out of 431 million packets sent, 100 million were successfully
> >> delivered and 331 million were lost.
> >
> > That is my issue.
> >
> > I kind of have trouble mapping that to the table below.
> > For example:
> >
> > | TAP | Transmitted | 1.136 Mpps | 1.130 Mpps | -0.6% |
> > | +-------------+--------------+----------------+----------+
> > | | Lost/s | 3.758 Mpps | 0 pps | |
> >
> > how can # of lost packets exceed the # of transmitted packets?
> >
> > Thanks!
>
> I just do use the sample script [1]:
>
> ./pktgen_sample02_multiqueue.sh -n 100000000 ...
>
> ... and this runs until 100_000_000 packets were sucessfully
> transmitted, independently of the lost packets/errors.
>
> [1] Link: https://www.kernel.org/doc/html/latest/networking/pktgen.html#sample-scripts
Confused. Are you saying "transmitted" is actually "received"? And the #
of packets sent is Transmitted + Lost?
> >
> >
> >>>
> >>>> I assume they would be visible as RX-DRP for TAP.
> >>>> For TAP + vhost-net I would have to rewrite the XDP drop
> >>>> program to count the number of dropped packets...
> >>>> And I would have to automate it...
> >>>>
> >>>>>>
> >>>>>> The previously introduced threshold to only wake after the queue stopped
> >>>>>> and half of the ring was consumed showed to be a descent choice:
> >>>>>> Waking the queue whenever a consume made space in the ring strongly
> >>>>>> degrades performance for tap, while waking only when the ring is empty
> >>>>>> is too late and also hurts throughput for tap & tap+vhost-net.
> >>>>>> Other ratios (3/4, 7/8) showed similar results (not shown here), so
> >>>>>> 1/2 was chosen for the sake of simplicity for both tun/tap and
> >>>>>> tun/tap+vhost-net.
> >>>>>>
> >>>>>> Test setup:
> >>>>>> AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
> >>>>>> Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2
> >>>>>> mitigations disabled.
> >>>>>>
> >>>>>> Note for tap+vhost-net:
> >>>>>> XDP drop program active in VM -> ~2.5x faster, slower for tap due to
> >>>>>> more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)
> >>>>>>
> >>>>>> +--------------------------+--------------+----------------+----------+
> >>>>>> | 1 thread | Stock | Patched with | diff |
> >>>>>> | sending | | fq_codel qdisc | |
> >>>>>> +------------+-------------+--------------+----------------+----------+
> >>>>>> | TAP | Transmitted | 1.136 Mpps | 1.130 Mpps | -0.6% |
> >>>>>> | +-------------+--------------+----------------+----------+
> >>>>>> | | Lost/s | 3.758 Mpps | 0 pps | |
> >>>>>> +------------+-------------+--------------+----------------+----------+
> >>>>>> | TAP | Transmitted | 3.858 Mpps | 3.816 Mpps | -1.1% |
> >>>>>> | +-------------+--------------+----------------+----------+
> >>>>>> | +vhost-net | Lost/s | 789.8 Kpps | 0 pps | |
> >>>>>> +------------+-------------+--------------+----------------+----------+
> >>>>>>
> >>>>>> +--------------------------+--------------+----------------+----------+
> >>>>>> | 2 threads | Stock | Patched with | diff |
> >>>>>> | sending | | fq_codel qdisc | |
> >>>>>> +------------+-------------+--------------+----------------+----------+
> >>>>>> | TAP | Transmitted | 1.117 Mpps | 1.087 Mpps | -2.7% |
> >>>>>> | +-------------+--------------+----------------+----------+
> >>>>>> | | Lost/s | 8.476 Mpps | 0 pps | |
> >>>>>> +------------+-------------+--------------+----------------+----------+
> >>>>>> | TAP | Transmitted | 3.679 Mpps | 3.464 Mpps | -5.8% |
> >>>>>> | +-------------+--------------+----------------+----------+
> >>>>>> | +vhost-net | Lost/s | 5.306 Mpps | 0 pps | |
> >>>>>> +------------+-------------+--------------+----------------+----------+
> >>>>>>
> >>>>>> Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> >>>>>> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> >>>>>> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> >>>>>> ---
> >>>>>> drivers/net/tun.c | 30 ++++++++++++++++++++++++++++--
> >>>>>> 1 file changed, 28 insertions(+), 2 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >>>>>> index efe809597622..c2a1618cc9db 100644
> >>>>>> --- a/drivers/net/tun.c
> >>>>>> +++ b/drivers/net/tun.c
> >>>>>> @@ -1011,6 +1011,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>>>> struct netdev_queue *queue;
> >>>>>> struct tun_file *tfile;
> >>>>>> int len = skb->len;
> >>>>>> + bool qdisc_present;
> >>>>>> + int ret;
> >>>>>>
> >>>>>> rcu_read_lock();
> >>>>>> tfile = rcu_dereference(tun->tfiles[txq]);
> >>>>>> @@ -1065,13 +1067,37 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>>>>
> >>>>>> nf_reset_ct(skb);
> >>>>>>
> >>>>>> - if (ptr_ring_produce(&tfile->tx_ring, skb)) {
> >>>>>> + queue = netdev_get_tx_queue(dev, txq);
> >>>>>> + qdisc_present = !qdisc_txq_has_no_queue(queue);
> >>>>>> +
> >>>>>> + spin_lock(&tfile->tx_ring.producer_lock);
> >>>>>> + ret = __ptr_ring_produce(&tfile->tx_ring, skb);
> >>>>>> + if (__ptr_ring_produce_peek(&tfile->tx_ring) && qdisc_present) {
> >>>>>> + netif_tx_stop_queue(queue);
> >>>>>> + /* Re-peek and wake if the consumer drained the ring
> >>>>>> + * concurrently in a race. smp_mb__after_atomic() pairs
> >>>>>> + * with the test_and_clear_bit() of netif_wake_subqueue()
> >>>>>> + * in __tun_wake_queue().
> >>>>>> + */
> >>>>>> + smp_mb__after_atomic();
> >>>>>> + if (!__ptr_ring_produce_peek(&tfile->tx_ring))
> >>>>>> + netif_tx_wake_queue(queue);
> >>>>>> + }
> >>>>>> + spin_unlock(&tfile->tx_ring.producer_lock);
> >>>>>> +
> >>>>>> + if (ret) {
> >>>>>> + /* If a qdisc is attached to our virtual device,
> >>>>>> + * returning NETDEV_TX_BUSY is allowed.
> >>>>>> + */
> >>>>>> + if (qdisc_present) {
> >>>>>> + rcu_read_unlock();
> >>>>>> + return NETDEV_TX_BUSY;
> >>>>>> + }
> >>>>>> drop_reason = SKB_DROP_REASON_FULL_RING;
> >>>>>> goto drop;
> >>>>>> }
> >>>>>>
> >>>>>> /* dev->lltx requires to do our own update of trans_start */
> >>>>>> - queue = netdev_get_tx_queue(dev, txq);
> >>>>>> txq_trans_cond_update(queue);
> >>>>>>
> >>>>>> /* Notify and wake up reader process */
> >>>>>> --
> >>>>>> 2.43.0
> >>>>>
> >>>
> >
^ permalink raw reply
* Re: [PATCH 2/2] net: thunderbolt: enlarge RX/TX ring and set NAPI weight for sustained load
From: Andrew Lunn @ 2026-04-28 14:39 UTC (permalink / raw)
To: Mika Westerberg
Cc: Benjamin Berman, Andreas Noever, Mika Westerberg, Yehezkel Bernat,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <20260428141954.GT557136@black.igk.intel.com>
> > Is there interrupt coalesce going on, and the coalesce time set too
> > high, so that by the time the interrupt fires the ring is full? Can
> > you play with ethtool -C?
>
> Thanks!
>
> I'll leave these to Benjamin and Claude AI to answer.
>
> One thing that could affect is the interrupt throttling that the hardware
> is doing. We have quite big value there by default. Lowering that may have
> affect as well. I just posted a patch series where one of the patches makes
> this configurable in the tbnet driver so you could apply that and play with
> the throttling value:
>
> https://lore.kernel.org/linux-usb/20260428072209.3084930-6-mika.westerberg@linux.intel.com/
So i guess this is interrupt coalesce by another name.
In netdev, the module parameter would get NACKed.
[Looks more closely at the code].
So, you are adding the module parameter in
drivers/net/thunderbolt/main.c. That clearly is netdev code. So sorry,
please don't do that.
But ethtool provides an API for configuring these things:
ethtool -C|--coalesce devname [adaptive-rx on|off] [adaptive-tx on|off]
[rx-usecs N] [rx-frames N] [rx-usecs-irq N] [rx-frames-irq N]
[tx-usecs N] [tx-frames N] [tx-usecs-irq N] [tx-frames-irq N]
[stats-block-usecs N] [pkt-rate-low N] [rx-usecs-low N]
[rx-frames-low N] [tx-usecs-low N] [tx-frames-low N]
[pkt-rate-high N] [rx-usecs-high N] [rx-frames-high N]
[tx-usecs-high N] [tx-frames-high N] [sample-interval N]
So i hope you can map these parameters to your tb_ring_throttling()
call.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx5: use internal dma pools for frag buf alloc
From: Leon Romanovsky @ 2026-04-28 14:47 UTC (permalink / raw)
To: Tariq Toukan
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Saeed Mahameed, Mark Bloch, netdev, linux-rdma,
linux-kernel, Gal Pressman, Dragos Tatulea, Moshe Shemesh,
Nimrod Oren
In-Reply-To: <20260428052920.219201-4-tariqt@nvidia.com>
On Tue, Apr 28, 2026 at 08:29:20AM +0300, Tariq Toukan wrote:
> From: Nimrod Oren <noren@nvidia.com>
>
> Add mlx5_dma_pool alloc/free paths, and wire mlx5_frag_buf allocation
> and free paths to use them.
>
> mlx5_frag_buf_alloc_node() now selects an mlx5_dma_pool to allocate
> fragments from, instead of directly allocating full coherent pages.
>
> mlx5_frag_buf_free() frees from the respective pool.
>
> mlx5_dma_pool_alloc() keeps allocation fast by maintaining pages with
> available indexes at the head of the list, so the common allocation path
> can take a free index immediately. New backing pages are allocated only
> when no free index is available.
>
> mlx5_dma_pool_free() returns released indexes to the pool and frees a
> backing page once all of its indexes become free. This avoids keeping
> fully free pages for the lifetime of the pool and reduces coherent DMA
> memory footprint.
>
> Signed-off-by: Nimrod Oren <noren@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
> .../net/ethernet/mellanox/mlx5/core/alloc.c | 185 ++++++++++++++----
> include/linux/mlx5/driver.h | 2 +
> 2 files changed, 154 insertions(+), 33 deletions(-)
<...>
> + if (WARN_ONCE(idx >= blocks_per_page,
> + "mlx5 dma pool invalid idx: %lu (max %d)\n",
> + idx, blocks_per_page - 1))
> + return;
<...>
> + if (WARN_ONCE(test_bit(idx, page->bitmap),
> + "mlx5 dma pool double free: idx=%lu block_shift=%u\n",
> + idx, pool->block_shift))
> + goto unlock;
<...>
> + if (WARN_ONCE(size <= 0, "mlx5_frag_buf non-positive size: %d\n", size))
> + return -EINVAL;
<...>
> + if (WARN_ONCE(node < 0 || node >= nr_node_ids || !node_possible(node),
> + "mlx5_frag_buf invalid node ID: %d\n", node))
> + return -EINVAL;
All WARN_ONCE() instances in this patch and the previous one are not
reachable. WARN_ONCE() should be used to detect states that are truly
impossible, not cases where the internal API is being misused.
There is no need for defensive programming when dealing with
in-kernel or in-driver APIs.
Thanks
^ permalink raw reply
* Re: [PATCH net-next v9 4/4] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
From: Simon Schippers @ 2026-04-28 14:55 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: willemdebruijn.kernel, jasowang, andrew+netdev, davem, edumazet,
kuba, pabeni, eperezma, leiyang, stephen, jon, tim.gebauer,
netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20260428103108-mutt-send-email-mst@kernel.org>
On 4/28/26 16:32, Michael S. Tsirkin wrote:
> On Tue, Apr 28, 2026 at 04:18:54PM +0200, Simon Schippers wrote:
>> On 4/28/26 16:10, Michael S. Tsirkin wrote:
>>> On Tue, Apr 28, 2026 at 03:41:20PM +0200, Simon Schippers wrote:
>>>> On 4/28/26 15:22, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 28, 2026 at 03:10:44PM +0200, Simon Schippers wrote:
>>>>>> On 4/28/26 14:50, Michael S. Tsirkin wrote:
>>>>>>> On Tue, Apr 28, 2026 at 02:38:59PM +0200, Simon Schippers wrote:
>>>>>>>> This commit prevents tail-drop when a qdisc is present and the ptr_ring
>>>>>>>> becomes full. Once an entry is successfully produced and the ptr_ring
>>>>>>>> reaches capacity, the netdev queue is stopped instead of dropping
>>>>>>>> subsequent packets.
>>>>>>>>
>>>>>>>> If producing an entry fails anyways due to a race, tun_net_xmit returns
>>>>>>>> NETDEV_TX_BUSY, again avoiding a drop. Such races are expected because
>>>>>>>> LLTX is enabled and the transmit path operates without the usual locking.
>>>>>>>>
>>>>>>>> If no qdisc is present, the previous tail-drop behavior is preserved.
>>>>>>>>
>>>>>>>> The existing __tun_wake_queue() function of the consumer races with the
>>>>>>>> producer for waking/stopping the netdev queue: the consumer may drain
>>>>>>>> the ring just as the producer stops the queue, leading to a permanent
>>>>>>>> stall. To avoid this, the producer re-checks the ring after stopping
>>>>>>>> and wakes the queue itself if space was just made. An
>>>>>>>> smp_mb__after_atomic() is required so the re-peek of the ring sees any
>>>>>>>> drain that the consumer performed.
>>>>>>>> smp_mb__after_atomic() pairs with the test_and_clear_bit() inside of
>>>>>>>> netif_wake_subqueue():
>>>>>>>>
>>>>>>>> Consumer CPU Producer CPU
>>>>>>>> ======================== =========================
>>>>>>>> __ptr_ring_consume()
>>>>>>>> netif_wake_subqueue() netif_tx_stop_queue()
>>>>>>>> /\ smp_mb__after_atomic()
>>>>>>>> || __ptr_ring_produce_peek()
>>>>>>>> contains RMW operation
>>>>>>>> test_and_clear_bit()
>>>>>>>> /\
>>>>>>>> ||
>>>>>>>> "Fully ordered RMW:
>>>>>>>> smp_mb() before + after"
>>>>>>>> - atomic_t.txt
>>>>>>>>
>>>>>>>> Benchmarks:
>>>>>>>> The benchmarks show a slight regression in raw transmission performance,
>>>>>>>> though no packets are lost anymore.
>>>>>>>
>>>>>>> Could you include the packets received as well?
>>>>>>> To demonstrate the gains/lack of loss.
>>>>>>>
>>>>>>
>>>>>> Do you mean the number of packets received by the VM?
>>>>>> They should just be the same as the number sent (shown below), right?
>>>>>
>>>>> Minus the loss? Which this is about, right?
>>>>
>>>> Yes. I simply calculated "Lost/s":
>>>>
>>>> elapsed_time = 100e6 / sent_pps
>>>> Lost/s = total_errors / elapsed_time
>>>>
>>>>
>>>> To get back total_errors for example for TAP
>>>> 1 thread sending:
>>>>
>>>> elapsed_time = 100e6 / 1.136Mpps = 88s
>>>>
>>>> 3758 Mpps = total_errors / 88s
>>>> <=> total_errors = 331 million packets
>>>>
>>>> So, out of 431 million packets sent, 100 million were successfully
>>>> delivered and 331 million were lost.
>>>
>>> That is my issue.
>>>
>>> I kind of have trouble mapping that to the table below.
>>> For example:
>>>
>>> | TAP | Transmitted | 1.136 Mpps | 1.130 Mpps | -0.6% |
>>> | +-------------+--------------+----------------+----------+
>>> | | Lost/s | 3.758 Mpps | 0 pps | |
>>>
>>> how can # of lost packets exceed the # of transmitted packets?
>>>
>>> Thanks!
>>
>> I just do use the sample script [1]:
>>
>> ./pktgen_sample02_multiqueue.sh -n 100000000 ...
>>
>> ... and this runs until 100_000_000 packets were sucessfully
>> transmitted, independently of the lost packets/errors.
>>
>> [1] Link: https://www.kernel.org/doc/html/latest/networking/pktgen.html#sample-scripts
>
> Confused. Are you saying "transmitted" is actually "received"? And the #
> of packets sent is Transmitted + Lost?
Sorry for my confusing answer.
Yes, "transmitted" in the table should be changed to "received".
And yes, as you said, the real # transmitted then is:
Received + Lost = 1.136 + 3.758 = 4.894 Mpps.
>
>>>
>>>
>>>>>
>>>>>> I assume they would be visible as RX-DRP for TAP.
>>>>>> For TAP + vhost-net I would have to rewrite the XDP drop
>>>>>> program to count the number of dropped packets...
>>>>>> And I would have to automate it...
>>>>>>
>>>>>>>>
>>>>>>>> The previously introduced threshold to only wake after the queue stopped
>>>>>>>> and half of the ring was consumed showed to be a descent choice:
>>>>>>>> Waking the queue whenever a consume made space in the ring strongly
>>>>>>>> degrades performance for tap, while waking only when the ring is empty
>>>>>>>> is too late and also hurts throughput for tap & tap+vhost-net.
>>>>>>>> Other ratios (3/4, 7/8) showed similar results (not shown here), so
>>>>>>>> 1/2 was chosen for the sake of simplicity for both tun/tap and
>>>>>>>> tun/tap+vhost-net.
>>>>>>>>
>>>>>>>> Test setup:
>>>>>>>> AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
>>>>>>>> Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2
>>>>>>>> mitigations disabled.
>>>>>>>>
>>>>>>>> Note for tap+vhost-net:
>>>>>>>> XDP drop program active in VM -> ~2.5x faster, slower for tap due to
>>>>>>>> more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)
>>>>>>>>
>>>>>>>> +--------------------------+--------------+----------------+----------+
>>>>>>>> | 1 thread | Stock | Patched with | diff |
>>>>>>>> | sending | | fq_codel qdisc | |
>>>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>>> | TAP | Transmitted | 1.136 Mpps | 1.130 Mpps | -0.6% |
>>>>>>>> | +-------------+--------------+----------------+----------+
>>>>>>>> | | Lost/s | 3.758 Mpps | 0 pps | |
>>>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>>> | TAP | Transmitted | 3.858 Mpps | 3.816 Mpps | -1.1% |
>>>>>>>> | +-------------+--------------+----------------+----------+
>>>>>>>> | +vhost-net | Lost/s | 789.8 Kpps | 0 pps | |
>>>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>>>
>>>>>>>> +--------------------------+--------------+----------------+----------+
>>>>>>>> | 2 threads | Stock | Patched with | diff |
>>>>>>>> | sending | | fq_codel qdisc | |
>>>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>>> | TAP | Transmitted | 1.117 Mpps | 1.087 Mpps | -2.7% |
>>>>>>>> | +-------------+--------------+----------------+----------+
>>>>>>>> | | Lost/s | 8.476 Mpps | 0 pps | |
>>>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>>> | TAP | Transmitted | 3.679 Mpps | 3.464 Mpps | -5.8% |
>>>>>>>> | +-------------+--------------+----------------+----------+
>>>>>>>> | +vhost-net | Lost/s | 5.306 Mpps | 0 pps | |
>>>>>>>> +------------+-------------+--------------+----------------+----------+
>>>>>>>>
>>>>>>>> Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
>>>>>>>> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
>>>>>>>> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
>>>>>>>> ---
>>>>>>>> drivers/net/tun.c | 30 ++++++++++++++++++++++++++++--
>>>>>>>> 1 file changed, 28 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>>>>>> index efe809597622..c2a1618cc9db 100644
>>>>>>>> --- a/drivers/net/tun.c
>>>>>>>> +++ b/drivers/net/tun.c
>>>>>>>> @@ -1011,6 +1011,8 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>>>> struct netdev_queue *queue;
>>>>>>>> struct tun_file *tfile;
>>>>>>>> int len = skb->len;
>>>>>>>> + bool qdisc_present;
>>>>>>>> + int ret;
>>>>>>>>
>>>>>>>> rcu_read_lock();
>>>>>>>> tfile = rcu_dereference(tun->tfiles[txq]);
>>>>>>>> @@ -1065,13 +1067,37 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>>>>
>>>>>>>> nf_reset_ct(skb);
>>>>>>>>
>>>>>>>> - if (ptr_ring_produce(&tfile->tx_ring, skb)) {
>>>>>>>> + queue = netdev_get_tx_queue(dev, txq);
>>>>>>>> + qdisc_present = !qdisc_txq_has_no_queue(queue);
>>>>>>>> +
>>>>>>>> + spin_lock(&tfile->tx_ring.producer_lock);
>>>>>>>> + ret = __ptr_ring_produce(&tfile->tx_ring, skb);
>>>>>>>> + if (__ptr_ring_produce_peek(&tfile->tx_ring) && qdisc_present) {
>>>>>>>> + netif_tx_stop_queue(queue);
>>>>>>>> + /* Re-peek and wake if the consumer drained the ring
>>>>>>>> + * concurrently in a race. smp_mb__after_atomic() pairs
>>>>>>>> + * with the test_and_clear_bit() of netif_wake_subqueue()
>>>>>>>> + * in __tun_wake_queue().
>>>>>>>> + */
>>>>>>>> + smp_mb__after_atomic();
>>>>>>>> + if (!__ptr_ring_produce_peek(&tfile->tx_ring))
>>>>>>>> + netif_tx_wake_queue(queue);
>>>>>>>> + }
>>>>>>>> + spin_unlock(&tfile->tx_ring.producer_lock);
>>>>>>>> +
>>>>>>>> + if (ret) {
>>>>>>>> + /* If a qdisc is attached to our virtual device,
>>>>>>>> + * returning NETDEV_TX_BUSY is allowed.
>>>>>>>> + */
>>>>>>>> + if (qdisc_present) {
>>>>>>>> + rcu_read_unlock();
>>>>>>>> + return NETDEV_TX_BUSY;
>>>>>>>> + }
>>>>>>>> drop_reason = SKB_DROP_REASON_FULL_RING;
>>>>>>>> goto drop;
>>>>>>>> }
>>>>>>>>
>>>>>>>> /* dev->lltx requires to do our own update of trans_start */
>>>>>>>> - queue = netdev_get_tx_queue(dev, txq);
>>>>>>>> txq_trans_cond_update(queue);
>>>>>>>>
>>>>>>>> /* Notify and wake up reader process */
>>>>>>>> --
>>>>>>>> 2.43.0
>>>>>>>
>>>>>
>>>
>
^ permalink raw reply
* [PATCH] net/sched: sch_dualpi2: Add missing skb check
From: Manas @ 2026-04-28 14:57 UTC (permalink / raw)
To: jhs, jiri, davem, edumazet, kuba, pabeni, horms, rakshitawasthi17
Cc: netdev, linux-kernel, Manas
A packed is dequeued using the function `dequeue_packet()` but there is
no check to see if a packet is dequeued. The assignment is always
considered as true resulting in null-ptr-deref
Fixes: 8f9516daedd6 ("sched: Add enqueue/dequeue of dualpi2 qdisc")
Reported-by: Manas <ghandatmanas@gmail.com>
Reported-by: Rakshit Awasthi <rakshitawasthi17@gmail.com>
Signed-off-by: Manas <ghandatmanas@gmail.com>
---
net/sched/sch_dualpi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c
index 241e6a46bd00..e360bf16d617 100644
--- a/net/sched/sch_dualpi2.c
+++ b/net/sched/sch_dualpi2.c
@@ -588,7 +588,7 @@ static struct sk_buff *dualpi2_qdisc_dequeue(struct Qdisc *sch)
now = ktime_get_ns();
- while ((skb = dequeue_packet(sch, q, &credit_change, now))) {
+ while ((skb = dequeue_packet(sch, q, &credit_change, now)) && skb) {
if (!q->drop_early && must_drop(sch, q, skb)) {
drop_and_retry(q, skb, sch, QDISC_DROP_CONGESTED);
continue;
--
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