* Re: [PATCH net] bridge: mcast: Fix a false positive lockdep splat
From: Paolo Abeni @ 2026-04-28 14:10 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge
Cc: davem, kuba, edumazet, razor, horms, herbert, linus.luessing
In-Reply-To: <20260426133435.207006-1-idosch@nvidia.com>
On 4/26/26 3:34 PM, Ido Schimmel wrote:
> Connecting two bridges on the same system [1] can result in a lockdep
> splat [2].
>
> The report is a false positive. Multicast queries are built and
> transmitted under the bridge multicast lock. When the outgoing port of
> one bridge is configured on top of another bridge, the transmit path
> re-enters bridge code and acquires the other bridge's multicast lock in
> order to snoop the query. Both lock instances share a single lockdep
> class, so lockdep flags the nested acquisition as an AA deadlock.
>
> Giving each bridge its own lock class will not solve the problem: the
> reverse topology would produce an ABBA splat with the same pair of
> classes. It also consumes a lockdep key per bridge.
>
> Instead, fix the problem by deferring the transmission of the queries to
> a workqueue. Build the skb and update querier state under the lock as
> before, then enqueue the skb on a per multicast context queue and
> schedule the work.
I must admit that introducing an additional WQ to fix a false positive
feels a bit overkill to me - even if I can't think of a better solution
on top of my head.
> Flush the work when the multicast context is de-initialized. At this
> stage the work cannot be requeued. There is no need to take a reference
> on skb->dev since the work cannot outlive the bridge or the bridge port.
>
> Use the high priority workqueue to reduce the delay between the enqueue
> time and the transmission time. With default settings (i.e., querier
> interval - 255 seconds, query interval - 125 seconds) the extra delay
> should not be a problem.
>
> [1]
> ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1
> ip link add name br0 up type bridge mcast_snooping 1 mcast_querier 1
> ip link add link br0 name br0.10 up master br1 type vlan id 10
>
> [2]
> ============================================
> WARNING: possible recursive locking detected
> 7.0.0-virtme-gb50c64a58a90 #1 Not tainted
> --------------------------------------------
checkpatch reports that the above separator may break tool. Possibly
just remove it from the commit message.
> ip/339 is trying to acquire lock:
> ffff888104f0b480 (&br->multicast_lock){+.-.}-{3:3}, at: br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
>
> but task is already holding lock:
> ffff888104f03480 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_query_expired (net/bridge/br_multicast.c:1904)
>
> [...]
>
> Call Trace:
> [...]
> br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
> br_multicast_ipv6_rcv (net/bridge/br_multicast.c:3988)
> br_dev_xmit (net/bridge/br_device.c:98 (discriminator 1))
> dev_hard_start_xmit (./include/linux/netdevice.h:5343 ./include/linux/netdevice.h:5352 net/core/dev.c:3888 net/core/dev.c:3904)
> __dev_queue_xmit (./include/linux/netdevice.h:3619 net/core/dev.c:4871)
> vlan_dev_hard_start_xmit (net/8021q/vlan_dev.c:131 (discriminator 1))
> dev_hard_start_xmit (./include/linux/netdevice.h:5343 ./include/linux/netdevice.h:5352 net/core/dev.c:3888 net/core/dev.c:3904)
> __dev_queue_xmit (./include/linux/netdevice.h:3619 net/core/dev.c:4871)
> br_dev_queue_push_xmit (net/bridge/br_forward.c:60)
> __br_multicast_send_query (net/bridge/br_multicast.c:1811 (discriminator 1))
> br_multicast_send_query (net/bridge/br_multicast.c:1889)
> br_multicast_port_query_expired (./include/linux/spinlock.h:390 net/bridge/br_multicast.c:1914)
> call_timer_fn (./arch/x86/include/asm/jump_label.h:37 ./include/trace/events/timer.h:127 kernel/time/timer.c:1749)
> [...]
>
> Fixes: eb1d16414339 ("bridge: Add core IGMP snooping support")
> Reported-by: syzbot+d7b7f1412c02134efa6d@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/000000000000c4c9d405f2643e01@google.com/
> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> net/bridge/br_multicast.c | 39 +++++++++++++++++++++++++++++++++++----
> net/bridge/br_private.h | 4 ++++
> 2 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 881d866d687a..252c46977ed5 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1776,6 +1776,28 @@ static void br_multicast_select_own_querier(struct net_bridge_mcast *brmctx,
> #endif
> }
>
> +static void br_multicast_port_query_queue_work(struct work_struct *work)
> +{
> + struct net_bridge_mcast_port *pmctx;
> + struct sk_buff *skb;
> +
> + pmctx = container_of(work, struct net_bridge_mcast_port,
> + query_queue_work);
> + while ((skb = skb_dequeue(&pmctx->query_queue)))
> + NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, dev_net(skb->dev),
> + NULL, skb, NULL, skb->dev, br_dev_queue_push_xmit);
> +}
> +
> +static void br_multicast_query_queue_work(struct work_struct *work)
> +{
> + struct net_bridge_mcast *brmctx;
> + struct sk_buff *skb;
> +
> + brmctx = container_of(work, struct net_bridge_mcast, query_queue_work);
> + while ((skb = skb_dequeue(&brmctx->query_queue)))
> + netif_rx(skb);
> +}
> +
> static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
> struct net_bridge_mcast_port *pmctx,
> struct net_bridge_port_group *pg,
> @@ -1804,9 +1826,8 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
> skb->dev = pmctx->port->dev;
> br_multicast_count(brmctx->br, pmctx->port, skb, igmp_type,
> BR_MCAST_DIR_TX);
> - NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT,
> - dev_net(pmctx->port->dev), NULL, skb, NULL, skb->dev,
> - br_dev_queue_push_xmit);
> + skb_queue_tail(&pmctx->query_queue, skb);
> + queue_work(system_highpri_wq, &pmctx->query_queue_work);
Also the AI reported concerns vs unbounded queue len looks relevant.
Usually the RX path is slower than TX, but i.e. asymmetric filtering
rules could reverse the scenario.
/P
^ permalink raw reply
* Re: [PATCH 9/9] thunderbolt: Add support for USB4STREAM
From: Mika Westerberg @ 2026-04-28 14:11 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, Yehezkel Bernat, Lukas Wunner, Andreas Noever,
Alan Borzeszkowski, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <2026042802-bobsled-envy-8e56@gregkh>
On Tue, Apr 28, 2026 at 07:54:51AM -0600, Greg KH wrote:
> On Tue, Apr 28, 2026 at 02:03:14PM +0200, Mika Westerberg wrote:
> > On Tue, Apr 28, 2026 at 05:57:37AM -0600, Greg KH wrote:
> > > On Tue, Apr 28, 2026 at 09:22:09AM +0200, Mika Westerberg wrote:
> > > > Introduce USB4STREAM protocol and Linux implementation. This allows two
> > > > (or more) hosts to transfer data directly over Thunderbolt/USB4 cable
> > > > through a character device without need to go through the network stack.
> > > >
> > > > Any application that supports read(2) and write(2) in some form should
> > > > be able to use the device without changes. The data is sent out to the
> > > > other side over a tunnel inside Thunderbolt/USB4 fabric. The character
> > > > device is called /dev/tbstreamX where X is the minor number starting
> > > > from 0.
> > > >
> > > > All stream devices need to be configured first. This is done through
> > > > ConfigFS interface. There can be multiple streams at the same time (this
> > > > depends on number of DMA rings and available HopIDs) and a single stream
> > > > supports traffic in both directions. For example there could be an
> > > > application that uses one stream as control channel and another one as
> > > > bi-directional data channel.
> > > >
> > > > A real use-case for this is to take a backup as a part of recovery
> > > > initramfs tooling (no need to setup networking or have ssh or similar
> > > > tooling as part of the initramfs). Say we want to backup the disk of
> > > > host1 to host2. First Thunderbolt/USB4 cable is connected between the
> > > > hosts (there can be devices in the middle too) then the receiving side
> > > > configures the stream:
> > > >
> > > > host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0
> > > > host2 # mkdir /sys/kernel/config/thunderbolt/stream/0-1.0/backup
> > > > host2 # echo -1 > /sys/kernel/config/thunderbolt/stream/0-1.0/backup/in_hopid
> > > > host2 # echo -1 > /sys/kernel/config/thunderbolt/stream/0-1.0/backup/out_hopid
> > > >
> > > > We use automatic HopID allocation (writing -1 to HopIDs) for simplicity.
> > > > >From this point forward the /dev/tbstream0 can be used pretty much as
> > > > regular file:
> > > >
> > > > host2 # dd if=/dev/tbstream0 of=/tmp/host1.nvme0n1.backup-$(date +%F) bs=256k
> > > >
> > > > The host that is being backed up then configures the stream accordingly:
> > > >
> > > > host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0
> > > > host1 # mkdir /sys/kernel/config/thunderbolt/stream/0-503.0/backup
> > > >
> > > > Here we take advantage of the fact that host2 also announces the active
> > > > streams through XDomain properties so the name "backup" gives us the
> > > > HopIDs. It is also possible to configure them manually in the same way
> > > > we did for host2.
> > > >
> > > > Then it is just a matter of copying the data over:
> > > >
> > > > host1 # dd if=/dev/nvme0n1 of=/dev/tbstream0 bs=256k
> > > >
> > > > Similarly it is possible to transfer parts of the filesystem. For
> > > > example copy contents of mydir over to the host2:
> > > >
> > > > host2 # gunzip < /dev/tbstream0 | tar xf -
> > > > host1 # tar cf - mydir | gzip > /dev/tbstream0
> > > >
> > > > Other end of the spectrum use-case is "borrowing" laptop (host1) camera
> > > > to desktop (host2):
> > > >
> > > > host2 # gst-launch-1.0 filesrc location=/dev/tbstream0 ! jpegdec ! videoconvert ! \
> > > > autovideosink
> > > >
> > > > host1 # gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw,width=1920,height=1080 ! \
> > > > jpegenc quality=90 ! filesink location=/dev/tbstream0
> > > >
> > > > Once the streams are no longer needed they can be removed:
> > > >
> > > > host1 # cd /sys/kernel/config/thunderbolt/stream/
> > > > host1 # rmdir -p 0-503.0/backup
> > > >
> > > > host2 # cd /sys/kernel/config/thunderbolt/stream
> > > > host2 # rmdir -p 0-1.0/backup
> > >
> > > Very cool, but shouldn't the above be in some documentation somewhere so
> > > that people know how to use it?
> >
> > Sure, I can add it part of the Documentation/admin-guide/thunderbolt.rs for
> > example.
> >
> > > And why do you need a whole major for this, why not just use a misc
> > > device that it dynamically created for every new dev?
> >
> > We do use this:
> >
> > ret = alloc_chrdev_region(&tbstream_devt, 0, TBSTREAM_DEV_MINORS,
> > "tbstream");
> >
> > that should be dynamically allocated, no?
>
> Yes, but you are using up a whole major number for this, and in reality
> there's only going to be 1-2, maybe 4, different devices needed at once,
> right? So just use the miscdev interface instead?
There could be 11 per host controller in Intel hardware (we have 12 DMA
rings, one of which is reserved for control traffic), and we have 2 host
conrollers in recent systems. Due to the dedicated flow control we use now
that's not possible but we are planning to make it to use shared flow
control instead which allows more.
Not sure if anybody ever will create that many, though.
Second thing is that we use cdev_device_add() to manage the char device and
the stream device as they are part of the same structure. I don't think
that can be done with miscdevice.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v7 13/14] ixd: add the core initialization
From: Larysa Zaremba @ 2026-04-28 14:12 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: <IA3PR11MB8986076E6260ADB50B05602CE5372@IA3PR11MB8986.namprd11.prod.outlook.com>
On Tue, Apr 28, 2026 at 10:50:54AM +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 13/14] ixd: add the core
> > initialization
> >
> > As the mailbox is setup, initialize the core. This makes use of the
> > send and receive mailbox message framework for virtchnl communication
> > between the driver and device Control Plane (CP).
> >
> > To start with, driver confirms the virtchnl version with the CP. Once
> > that is done, it requests and gets the required capabilities and
> > resources needed such as max vectors, queues, vports etc.
> >
> > Use a unified way of handling the virtchnl messages, where a single
> > function handles all related memory management and the caller only
> > provides the callbacks to fill the send buffer and to handle the
> > response.
> >
> > Place generic control queue message handling separately to facilitate
> > the addition of protocols other than virtchannel in the future.
> >
> > Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com>
> > Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> > Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@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>
> > ---
> > drivers/net/ethernet/intel/ixd/Makefile | 2 +
> > drivers/net/ethernet/intel/ixd/ixd.h | 10 +
> > drivers/net/ethernet/intel/ixd/ixd_ctlq.c | 149 +++++++++++++++
> > drivers/net/ethernet/intel/ixd/ixd_ctlq.h | 33 ++++
> > drivers/net/ethernet/intel/ixd/ixd_lib.c | 25 ++-
> > drivers/net/ethernet/intel/ixd/ixd_main.c | 3 +
> > drivers/net/ethernet/intel/ixd/ixd_virtchnl.c | 178
> > ++++++++++++++++++ drivers/net/ethernet/intel/ixd/ixd_virtchnl.h |
> > 12 ++
> > 8 files changed, 411 insertions(+), 1 deletion(-) create mode 100644
> > drivers/net/ethernet/intel/ixd/ixd_ctlq.c
> > create mode 100644 drivers/net/ethernet/intel/ixd/ixd_ctlq.h
> > create mode 100644 drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
> > create mode 100644 drivers/net/ethernet/intel/ixd/ixd_virtchnl.h
> >
> > diff --git a/drivers/net/ethernet/intel/ixd/Makefile
> > b/drivers/net/ethernet/intel/ixd/Makefile
> > index 164b2c86952f..90abf231fb16 100644
> > --- a/drivers/net/ethernet/intel/ixd/Makefile
> > +++ b/drivers/net/ethernet/intel/ixd/Makefile
> > @@ -6,5 +6,7 @@
> > obj-$(CONFIG_IXD) += ixd.o
> >
> > ixd-y := ixd_main.o
> > +ixd-y += ixd_ctlq.o
> > ixd-y += ixd_dev.o
> > ixd-y += ixd_lib.o
> > +ixd-y += ixd_virtchnl.o
> > diff --git a/drivers/net/ethernet/intel/ixd/ixd.h
> > b/drivers/net/ethernet/intel/ixd/ixd.h
> > index 99c44f2aa659..98d1f22534b5 100644
> > --- a/drivers/net/ethernet/intel/ixd/ixd.h
> > +++ b/drivers/net/ethernet/intel/ixd/ixd.h
> > @@ -10,19 +10,29 @@
> > * struct ixd_adapter - Data structure representing a CPF
> > * @cp_ctx: Control plane communication context
> > * @init_task: Delayed initialization after reset
>
> ...
>
> > diff --git a/drivers/net/ethernet/intel/ixd/ixd_ctlq.h
> > b/drivers/net/ethernet/intel/ixd/ixd_ctlq.h
> > new file mode 100644
> > index 000000000000..f450a3a0828f
> > --- /dev/null
> > +++ b/drivers/net/ethernet/intel/ixd/ixd_ctlq.h
> > @@ -0,0 +1,33 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/* Copyright (C) 2025 Intel Corporation */
> > +
> > +#ifndef _IXD_CTLQ_H_
> > +#define _IXD_CTLQ_H_
> > +
> > +#include "linux/intel/virtchnl2.h"
> Every other file use #include <linux/intel/virtchnl2.h> why do you need #include "linux/intel/virtchnl2.h" here?
> Please explain
This is a small oversight.
>
> > +
> > +#define IXD_CTLQ_TIMEOUT 2000
> > +
>
> ...
>
> > --
> > 2.47.0
>
^ permalink raw reply
* 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
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