* [GIT PULL] wireless-2026-04-08
From: Johannes Berg @ 2026-04-08 8:15 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
Hi,
So in a way I'd hoped it wouldn't come to this, but while I
was out last week a couple of things came in that seemed
relevant enough to squeeze in now. I guess it wouldn't be
much of an issue if not, but I figured I'd try anyway :)
Please pull and let us know if there's any problem.
Thanks,
johannes
The following changes since commit f8f5627a8aeab15183eef8930bf75ba88a51622f:
Merge tag 'net-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2026-04-02 09:57:06 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git tags/wireless-2026-04-08
for you to fetch changes up to ea245d78dec594372e27d8c79616baf49e98a4a1:
net: rfkill: prevent unlimited numbers of rfkill events from being created (2026-04-07 12:35:04 +0200)
----------------------------------------------------------------
A few last-minute fixes:
- rfkill: prevent boundless event list
- rt2x00: fix USB resource management
- brcmfmac: validate firmware IDs
- brcmsmac: fix DMA free size
----------------------------------------------------------------
Greg Kroah-Hartman (1):
net: rfkill: prevent unlimited numbers of rfkill events from being created
Johan Hovold (1):
wifi: rt2x00usb: fix devres lifetime
Pengpeng Hou (1):
wifi: brcmfmac: validate bsscfg indices in IF events
Thomas Fourier (1):
wifi: brcmsmac: Fix dma_free_coherent() size
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 5 ++++
.../net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 2 +-
net/rfkill/core.c | 35 +++++++++++++++-------
4 files changed, 31 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value
From: Morduan Zang @ 2026-04-08 8:18 UTC (permalink / raw)
To: horms
Cc: andrew+netdev, davem, edumazet, kuba, linux-kernel, linux-usb,
netdev, pabeni, petkan, syzbot+9db6c624635564ad813c, zhangdandan
In-Reply-To: <20260403154538.GA187715@horms.kernel.org>
> I wonder if we can handle this a bit more succinctly,
> while still making it clear that the error is handled.
> Something like this:
>
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index 4cda0643afb6..816759ced56c 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
> @@ -722,7 +722,8 @@ static void set_carrier(struct net_device *netdev)
> rtl8150_t *dev = netdev_priv(netdev);
> short tmp;
>
> - get_registers(dev, CSCR, 2, &tmp);
> + if (get_registers(dev, CSCR, 2, &tmp) < 0)
> + tmp = 0;
> if (tmp & CSCR_LINK_STATUS)
> netif_carrier_on(netdev);
> else
Thanks for your suggestion.
I agree that errors should be handled explicitly, but I prefer not to force the carrier off
when CSCR read fails. The control transfer error here may be transient, and treating it
as a link break would cause the carrier state to toggle frequently.
Therefore, if the get_registers() call fails, should we keep the previous carrier state and
return directly? (Perhaps with a rate-limited warning as an option), while still avoiding
the use of uninitialized stack values.
If agreed, I will send a v2 incorporating the suggestions.
^ permalink raw reply
* Re: [PATCH net-next v5 1/2] net: hsr: require valid EOT supervision TLV
From: Luka Gejak @ 2026-04-08 8:19 UTC (permalink / raw)
To: Fernando Fernandez Mancera, davem, edumazet, kuba, pabeni
Cc: netdev, fmaurer, horms
In-Reply-To: <15888967-8372-4c6b-b3ec-3cb336dcebbb@suse.de>
On April 8, 2026 10:05:31 AM GMT+02:00, Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>On 4/8/26 9:48 AM, Fernando Fernandez Mancera wrote:
>> On 4/7/26 6:25 PM, luka.gejak@linux.dev wrote:
>>> From: Luka Gejak <luka.gejak@linux.dev>
>>>
>>> Supervision frames are only valid if terminated with a zero-length EOT
>>> TLV. The current check fails to reject non-EOT entries as the terminal
>>> TLV, potentially allowing malformed supervision traffic.
>>>
>>> Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT
>>> with a length of zero, and properly linearizing the TLV header before
>>> access.
>>>
>>> Assisted-by: Gemini:Gemini-3.1-flash
>>> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
>>> ---
>>> net/hsr/hsr_forward.c | 20 +++++++++-----------
>>> 1 file changed, 9 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
>>> index 0aca859c88cb..eb89cc44eac0 100644
>>> --- a/net/hsr/hsr_forward.c
>>> +++ b/net/hsr/hsr_forward.c
>>> @@ -82,35 +82,33 @@ static bool is_supervision_frame(struct hsr_priv *hsr, struct sk_buff *skb)
>>> hsr_sup_tag->tlv.HSR_TLV_length != sizeof(struct hsr_sup_payload))
>>> return false;
>>> - /* Get next tlv */
>>> + /* Get next TLV */
>>> total_length += hsr_sup_tag->tlv.HSR_TLV_length;
>>> - if (!pskb_may_pull(skb, total_length))
>>> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
>>> return false;
>>> skb_pull(skb, total_length);
>>> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
>>> skb_push(skb, total_length);
>>> - /* if this is a redbox supervision frame we need to verify
>>> - * that more data is available
>>> - */
>>> + /* If this is a RedBox supervision frame, verify additional data */
>>> if (hsr_sup_tlv->HSR_TLV_type == PRP_TLV_REDBOX_MAC) {
>>> - /* tlv length must be a length of a mac address */
>>> + /* TLV length must be the size of a MAC address */
>>> if (hsr_sup_tlv->HSR_TLV_length != sizeof(struct hsr_sup_payload))
>>> return false;
>>> - /* make sure another tlv follows */
>>> + /* Make sure another TLV follows */
>>> total_length += sizeof(struct hsr_sup_tlv) + hsr_sup_tlv- >HSR_TLV_length;
>>> - if (!pskb_may_pull(skb, total_length))
>>> + if (!pskb_may_pull(skb, total_length + sizeof(struct hsr_sup_tlv)))
>>
>> Hi Luka,
>>
>> why is the length adjusted here? The current total length was adjusted correctly above see:
>>
>
>Never mind, it makes sense as the total_length must point to the beginning of the next TLV.
>
>LGTM,
>
>Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
>
>Thanks,
>Fernando.
>
Hi Fernando,
Thank you for the follow-up and the reviewed-by tag.
I was actually just about to send an explanation regarding the
pskb_may_pull() logic, but that seems unnecessary now. I'm glad it
makes sense on your end as well.
Best regards,
Luka
>>> return false;
>>> - /* get next tlv */
>>> + /* Get next TLV */
>>> skb_pull(skb, total_length);
>>> hsr_sup_tlv = (struct hsr_sup_tlv *)skb->data;
>>> skb_push(skb, total_length);
>>> }
>>> - /* end of tlvs must follow at the end */
>>> - if (hsr_sup_tlv->HSR_TLV_type == HSR_TLV_EOT &&
>>> + /* Supervision frame must end with EOT TLV */
>>> + if (hsr_sup_tlv->HSR_TLV_type != HSR_TLV_EOT ||
>>> hsr_sup_tlv->HSR_TLV_length != 0)
>>> return false;
>>
>
^ permalink raw reply
* Re: [PATCH v2] rxrpc/proc: size address buffers for %pISpc output
From: Pengpeng Hou @ 2026-04-08 8:21 UTC (permalink / raw)
To: David Howells; +Cc: linux-afs, netdev, linux-kernel, Pengpeng Hou
In-Reply-To: <20260406170001.2-rxrpc-proc-v2-pengpeng@iscas.ac.cn>
Hi David,
That's possible for some builds, yes.
My concern here is a bit narrower: with the current %pISpc formatter, the
ISATAP case can produce 50 visible characters, i.e. 51 bytes including
the trailing NUL, while these helpers pass a declared char[50] object to
sprintf().
So even if a particular compiler/ABI happens to pad the stack slot out to
sizeof(long) or more, that would only be incidental code generation slack.
It still writes one byte past the end of the declared object, and whether
that lands in padding or in another live stack slot depends on the build
and the specific function layout.
In particular, rxrpc_local_seq_show() has only a single local char[50]
buffer, so there is no source-level guarantee of spare space there either.
The patch is really just making the object size match the formatter's
actual maximum output, so we don't depend on incidental stack padding.
Thanks,
Pengpeng
^ permalink raw reply
* Re: [PATCH net v6 4/4] macsec: Support VLAN-filtering lower devices
From: Sabrina Dubroca @ 2026-04-08 8:25 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: pabeni@redhat.com, andrew+netdev@lunn.ch, davem@davemloft.net,
linux-kselftest@vger.kernel.org, Dragos Tatulea, shuah@kernel.org,
sdf@fomichev.me, kuba@kernel.org, horms@kernel.org,
edumazet@google.com, netdev@vger.kernel.org
In-Reply-To: <e2eefeb7033caa859551834d3448a77b7af3c7d4.camel@nvidia.com>
2026-04-07, 15:07:47 +0000, Cosmin Ratiu wrote:
> On Thu, 2026-04-02 at 16:48 +0200, Sabrina Dubroca wrote:
> > If this happens on a real device, the VLAN filters will be broken.
> > I'm
> > not sure what the right behavior would be:
> >
> > 1. reject the request to enable offload
> > 2. switch to promiscuous mode
>
> I implemented and tested option 1. In the unlikely scenario adding VLAN
> filters prevents offloading
How unlikely is it? Resource allocation, talking to HW, device limits,
anything else that could fail?
> , it's better for the driver to be explicit
> and let the user turn on promisc mode themselves. Keeping track of
> whether VLAN filters failed and promisc was used as a fallback adds
> some extra complexity.
If it's indeed (very) unlikely, sure. There's still a bit of a
regression/change of behavior for users compared to before the
IFF_UNICAST_FLT patch, but I think we can wait until someone
complains, and then add the tracking if that happens.
> What would be the point of IFF_UNICAST_FLT then?
The point is that this would just be a fallback.
> Please let me know if you agree with this approach, so I can send v8
> with it.
If you can confirm it's on the "very unlikely" side, yes, this
approach sounds ok. Thanks.
> > OTOH maybe we don't need to care, since __netdev_update_features also
> > (kind of) ignores those errors:
> >
[...]
>
> Well, in this case we have the chance to do something nicer (even
> proper error message back to the user via extack) for a small
(That reminds me I have a branch of "macsec: add extack to X" patches
I still need to polish and submit. I don't think I'll get to it before
the merge window opens, I'll rebase on top of your changes.)
> complexity cost. Perhaps the VLAN filter handling could be improved
> separately.
I'm not sure if this would be an "improvement to VLAN filter handling"
or a "(breaking) change of user-visible behavior". Probably
improvement. Or maybe it's "unlikely enough" that nobody has ever
cared.
--
Sabrina
^ permalink raw reply
* Re: [PATCH net v2] net/sched: cls_fw: fix NULL dereference of "old" filters before change()
From: Davide Caratti @ 2026-04-08 8:28 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Xiang Mei, netdev, Victor Nogueira
In-Reply-To: <CAM0EoMm2MpiZ-Rn7PVE8rYq8bOkrqs+0PAjuLi23iLN6Eih2sg@mail.gmail.com>
On Fri, Apr 03, 2026 at 02:59:22PM -0400, Jamal Hadi Salim wrote:
> On Fri, Apr 3, 2026 at 12:04 PM Davide Caratti <dcaratti@redhat.com> wrote:
> >
> > Like pointed out by Sashiko [1],
>
> Just found out about this ;-> So bye-bye old AI? ;->
> I must say, finding this specific bug is impressive.
[...]
> Observation on consistency pov:
> You will always get a "q" when you invoke tcf_block_q() if there are
> no shared blocks attached. But that doesnt mean the "create"
> configuration is complete; it is only complete if step 3 above
> completes. This is because we are not sure if change() will result in
> "old" or "new" lookup setup. So the check you added for q may be
> inconsistent from that perspective and fw should have returned -1 like
> all classifiers...
"Hello Jamal, you are absolutely right! (emoji with fire) However, ..." :)
> I cant think of a simple solution to verify if the config is
> "inconsistent" other than to add something that gets checked in the
> datapath (and when absent, return -1)
^^ This. Specifically for cls_fw, that would mean converting fw_change() to
allocate some control data also for the "old" uapi, and I think it's too
much effort for the legacy.
IIUC the inconsistent behavior is: for a small amount of time, fwmark
classifier used in the "old" way would classify also when the filter's
'handle' is not zero.
> From that perspective, your check is not catastrophic, so it may be ok.
> At minimal the Fixes: needs to change to Vlads commit? Good news is
> only fw _seems_ to suffer from this challenge...
This is also what I understood by reading the code. Sure, I will edit
the Fixes: tag. Thanks for reading!
--
davide
^ permalink raw reply
* Re: [PATCH net] xfrm_user: fix info leak in build_mapping()
From: Steffen Klassert @ 2026-04-08 8:32 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Greg Kroah-Hartman, netdev, linux-kernel, Herbert Xu,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman
In-Reply-To: <20260407181211.5419f2cc@kernel.org>
On Tue, Apr 07, 2026 at 06:12:11PM -0700, Jakub Kicinski wrote:
> On Tue, 7 Apr 2026 07:51:15 +0200 Greg Kroah-Hartman wrote:
> > > > I guess nlmsg_append() would work? It tries to do some zeroing out for
> > > > alignment for some reason...
> > > >
> > > > Want me to do that? I don't have a way to test any of this, I just
> > > > found it using some static code analysis tools that looked at holes in
> > > > structures.
> > >
> > > Do you have any more Netlink leaks in the queue? If you do let's do it,
> > > if you don't we can wait until the next victi^w patch to arrive.
> >
> > I do not have any more, sorry. So is it worth it for just these 2?
> > Your call :)
>
> These are fine. I would have applied but I think Steffen will take them
> via the ipsec tree first (LMK if that's not the plan, Steffen)
I have them already in my ipsec testing branch, will be merged today.
Thanks!
^ permalink raw reply
* Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value
From: Michal Pecio @ 2026-04-08 8:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Petko Manolov, Simon Horman, Morduan Zang, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-usb, netdev, linux-kernel, syzbot+9db6c624635564ad813c
In-Reply-To: <76d6b341-27d5-44aa-92fb-3b8966d609df@lunn.ch>
On Mon, 6 Apr 2026 01:38:06 +0200, Andrew Lunn wrote:
> > > - get_registers(dev, CSCR, 2, &tmp);
> > > + if (get_registers(dev, CSCR, 2, &tmp) < 0)
> > > + tmp = 0;
> > > if (tmp & CSCR_LINK_STATUS)
> > > netif_carrier_on(netdev);
> > > else
> >
> > I was wondering if calling netif_carrier_off() is the right thing
> > to do in case get_registers() fail.
> >
> > There are multiple get_registers() calls that don't check the error
> > and if we do this in set_carrier() maybe we should do the same
> > thing across the whole driver?
>
> What does it actually mean if get_registers() fails? The device is
> gone? Hot unplugged? If so, you are going to get a cascade of errors,
> and then hopefully the USB core code removes the device?
>
> Are there any legitimate reasons for get_registers() to fail if the
> device is still plugged in?
In principle it might be temporary EMI or a flaky cable. These errors
rarely reach drivers due to retries in USB layer, but in extreme cases
the device may be in unknown state and it may become functional later.
IIRC net layer has some operations which are presumed trivial enough
that they would never fail, so this could be annoying.
It does seem rare enough in practice that for 25 years nobody noticed
carrier status being set to a random vaule by this driver.
BTW, some functions like rtl8150_reset() pre-set data to a value which
will be safe in case of get_register() failure. But here, unhandled
set_register() error is dodgy - the 0x10 bit may never turn on.
Regards,
Michal
^ permalink raw reply
* Re: [PATCH 1/3] io_uring: fix pinned pages and pages array leak in io_region_pin_pages()
From: Pavel Begunkov @ 2026-04-08 8:34 UTC (permalink / raw)
To: KobaK, Jens Axboe; +Cc: Keith Busch, Ming Lei, io-uring, netdev, linux-kernel
In-Reply-To: <20260408065408.2017967-2-kobak@nvidia.com>
On 4/8/26 07:54, KobaK wrote:
> From: Koba Ko <kobak@nvidia.com>
>
> When io_pin_pages() succeeds but the subsequent nr_pages sanity check
> fires (WARN_ON_ONCE), the function returns -EFAULT without unpinning the
> user pages or freeing the kvmalloc'd pages array. The caller's cleanup
> via io_free_region() won't help either, because mr->pages was never
> assigned — so the entire cleanup block is skipped.
>
> Add unpin_user_pages() and kvfree() before the error return to prevent
> the leak.
>
> Fixes: a90558b36ccee ("io_uring/memmap: helper for pinning region pages")
> Signed-off-by: Koba Ko <kobak@nvidia.com>
It's a WARN path, it should never happen, but if it does, that means
io_pin_pages() is buggy, and it's better to leak rather than risk
something nastier.
> ---
> io_uring/memmap.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/io_uring/memmap.c b/io_uring/memmap.c
> index e6958968975a8..9f0d3750ce3bc 100644
> --- a/io_uring/memmap.c
> +++ b/io_uring/memmap.c
> @@ -141,8 +141,11 @@ static int io_region_pin_pages(struct io_mapped_region *mr,
> pages = io_pin_pages(reg->user_addr, size, &nr_pages);
> if (IS_ERR(pages))
> return PTR_ERR(pages);
> - if (WARN_ON_ONCE(nr_pages != mr->nr_pages))
> + if (WARN_ON_ONCE(nr_pages != mr->nr_pages)) {
> + unpin_user_pages(pages, nr_pages);
> + kvfree(pages);
> return -EFAULT;
> + }
>
> mr->pages = pages;
> mr->flags |= IO_REGION_F_USER_PROVIDED;
--
Pavel Begunkov
^ permalink raw reply
* [PATCH iwl-next] igb: use ktime_get_real helpers in igb_ptp_reset()
From: Aleksandr Loktionov @ 2026-04-08 8:35 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Jacob Keller, Simon Horman
Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
ktime_get_real_ns() and ktime_to_timespec64(ktime_get_real()) with
ktime_get_real_ts64() in igb_ptp_reset(). Using the combined helpers
avoids the unnecessary intermediate ktime_t variable and makes the
intent clearer.
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Suggested-by: Simon Horman <horms@kernel.org>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/igb/igb_ptp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index bd85d02..638d824 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -1500,12 +1500,13 @@ void igb_ptp_reset(struct igb_adapter *adapter)
/* Re-initialize the timer. */
if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211)) {
- struct timespec64 ts = ktime_to_timespec64(ktime_get_real());
+ struct timespec64 ts;
+ ktime_get_real_ts64(&ts);
igb_ptp_write_i210(adapter, &ts);
} else {
timecounter_init(&adapter->tc, &adapter->cc,
- ktime_to_ns(ktime_get_real()));
+ ktime_get_real_ns());
}
out:
spin_unlock_irqrestore(&adapter->tmreg_lock, flags);
--
2.52.0
^ permalink raw reply related
* RE: [PATCH v4 net-next 09/14] net: dsa: add NETC switch tag support
From: Wei Fang @ 2026-04-08 8:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, f.fainelli@gmail.com, Frank Li,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011736.1795610-1-kuba@kernel.org>
> > diff --git a/net/dsa/tag_netc.c b/net/dsa/tag_netc.c
> > new file mode 100644
> > index 000000000000..addd41f7f1b6
> > --- /dev/null
> > +++ b/net/dsa/tag_netc.c
> [ ... ]
> > +static void *netc_fill_common_tp_tag(struct sk_buff *skb,
> > + struct net_device *ndev,
> > + u8 subtype, int tag_len)
> > +{
> > + struct dsa_port *dp = dsa_user_to_port(ndev);
> > + u16 queue = skb_get_queue_mapping(skb);
> > + u8 ipv = netdev_txq_to_tc(ndev, queue);
>
> What happens here if the interface doesn't have traffic classes configured?
netdev_txq_to_tc() will return 0 if not TC configured, I mean ndev->num_tc is
0.
>
> By default, netdev_txq_to_tc() returns -1. Because ipv is an unsigned 8-bit
> integer, this casts to 255.
Okay, this is a potential bug when we add TC_SETUP_QDISC_MQPRIO
support. I will fix it.
>
> When this is later passed to FIELD_PREP(NETC_TAG_IPV, ipv) in
> netc_fill_common_tag(), the macro blindly masks the variable, silently
> forcing the IPV field to 7 (the maximum priority) for all default,
> unconfigured traffic. Valid TC values greater than 7 would also be silently
> truncated.
>
> Does this code bypass the intended QoS mechanisms?
No, configure IPV to send packets according to the expected TC.
>
> > + void *tag;
> > +
> > + skb_push(skb, tag_len);
> > + dsa_alloc_etype_header(skb, tag_len);
> > +
> > + tag = dsa_etype_header_pos_tx(skb);
> > + memset(tag + NETC_TAG_CMN_LEN, 0, tag_len - NETC_TAG_CMN_LEN);
> > + netc_fill_common_tag(tag, NETC_TAG_TO_PORT, subtype,
> > + dp->ds->index, dp->index, ipv);
>
> Will this break communication for standard single-switch setups?
>
> The driver passes dp->ds->index as the hardware switch ID here, which
> defaults to 0 for the first switch in a DSA tree. However, on the receive
> path, frames stamped with switch ID 0 are rejected.
>
> If the physical switch hardware uses an ID greater than 0, frames will fail
> the lookup in dsa_conduit_find_user() on receive because the software index
> is 0.
We added the 'dsa,member' property to the netc switch DT-binding doc, specifying
that the 'member' (switch index) value cannot be 0. Furthermore, the netc switch
driver also checks the switch index to ensure it is not 0. Therefore, the software index
and hardware index are equal.
>
> > +
> > + return tag;
> > +}
> [ ... ]
> > +static struct sk_buff *netc_rcv(struct sk_buff *skb,
> > + struct net_device *ndev)
> > +{
> > + struct netc_tag_cmn *tag_cmn;
> > + int tag_len, sw_id, port;
> [ ... ]
> > + if (tag_cmn->qos & NETC_TAG_QV)
> > + skb->priority = FIELD_GET(NETC_TAG_IPV, tag_cmn->qos);
> > +
> > + sw_id = NETC_TAG_SWITCH & tag_cmn->switch_port;
>
> This isn't a bug, but is there a reason to use a raw bitwise AND for sw_id
> instead of using FIELD_GET(NETC_TAG_SWITCH, ...) to match how the port
> field is extracted just below this?
I think either is fine, the final result is the same. I just wrote it this way for
convenience during implementation.
^ permalink raw reply
* Re: [PATCH 2/3] io_uring/rsrc: use io_cache_free for node in io_buffer_register_bvec error path
From: Pavel Begunkov @ 2026-04-08 8:35 UTC (permalink / raw)
To: KobaK, Jens Axboe; +Cc: Keith Busch, Ming Lei, io-uring, netdev, linux-kernel
In-Reply-To: <20260408065408.2017967-3-kobak@nvidia.com>
On 4/8/26 07:54, KobaK wrote:
> From: Koba Ko <kobak@nvidia.com>
>
> io_buffer_register_bvec() allocates the rsrc node via
> io_rsrc_node_alloc() which pulls from ctx->node_cache. On imu allocation
> failure, the node is freed with raw kfree() instead of
> io_cache_free(&ctx->node_cache, node), bypassing the cache return path
> and wasting a reuse opportunity. Every other error path in this file
> correctly uses io_cache_free for nodes.
>
> Fixes: 27cb27b6d5ea4 ("io_uring: add support for kernel registered bvecs")
> Signed-off-by: Koba Ko <kobak@nvidia.com>
> ---
> io_uring/rsrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c
> index 1b96ab5e98c99..6f46cf9cd13d7 100644
> --- a/io_uring/rsrc.c
> +++ b/io_uring/rsrc.c
> @@ -961,7 +961,7 @@ int io_buffer_register_bvec(struct io_uring_cmd *cmd, struct request *rq,
> */
> imu = io_alloc_imu(ctx, blk_rq_nr_phys_segments(rq));
> if (!imu) {
> - kfree(node);
> + io_cache_free(&ctx->node_cache, node);
Looks like it was already patched a week ago
--
Pavel Begunkov
^ permalink raw reply
* [PATCH iwl-next] e1000e: use ktime_get_real_ns() in e1000e_systim_reset()
From: Aleksandr Loktionov @ 2026-04-08 8:36 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Jacob Keller, Simon Horman
Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
ktime_get_real_ns() in e1000e_systim_reset(). Using the combined helper
avoids the unnecessary intermediate ktime_t variable and makes the
intent clearer.
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Suggested-by: Simon Horman <horms@kernel.org>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9befdac..6278ce9 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3943,7 +3943,7 @@ static void e1000e_systim_reset(struct e1000_adapter *adapter)
/* reset the systim ns time counter */
spin_lock_irqsave(&adapter->systim_lock, flags);
timecounter_init(&adapter->tc, &adapter->cc,
- ktime_to_ns(ktime_get_real()));
+ ktime_get_real_ns());
spin_unlock_irqrestore(&adapter->systim_lock, flags);
/* restore the previous hwtstamp configuration settings */
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net] nfc: llcp: add missing return after LLCP_CLOSED checks
From: Eric Dumazet @ 2026-04-08 8:40 UTC (permalink / raw)
To: Junxi Qian; +Cc: netdev, davem, kuba, pabeni, horms
In-Reply-To: <20260408081006.3723-1-qjx1298677004@gmail.com>
On Wed, Apr 8, 2026 at 1:10 AM Junxi Qian <qjx1298677004@gmail.com> wrote:
>
> In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket
> state is LLCP_CLOSED, the code correctly calls release_sock() and
> nfc_llcp_sock_put() but fails to return. Execution falls through to
> the remainder of the function, which calls release_sock() and
> nfc_llcp_sock_put() again. This results in a double release_sock()
> and a refcount underflow via double nfc_llcp_sock_put(), leading to
> a use-after-free.
>
> Add the missing return statements after the LLCP_CLOSED branches
> in both functions to prevent the fall-through.
>
> Fixes: d646960f7986 ("NFC: Initial LLCP support")
> Signed-off-by: Junxi Qian <qjx1298677004@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks!
^ permalink raw reply
* [net-next v1 v1 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Remove JH8100 dt-bindings because do not support it now.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 ++++---------------
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 313a15331661..0d1962980f57 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -30,10 +30,6 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
- - items:
- - const: starfive,jh8100-dwmac
- - const: starfive,jh7110-dwmac
- - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -120,25 +116,11 @@ allOf:
minItems: 3
maxItems: 3
- if:
- properties:
- compatible:
- contains:
- const: starfive,jh8100-dwmac
- then:
- properties:
- resets:
- maxItems: 1
-
- reset-names:
- const: stmmaceth
- else:
- properties:
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
2.17.1
^ permalink raw reply related
* [net-next v1 v1 2/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add StarFive JHB100 dwmac support and compatible.
The JHB100 dwmac shares the same driver code as the JH7110 dwmac,
which contains 2 SGMII interfaces, 1 RGMII/RMII interface and
1 RMII interface.
JHB100 dwmacc has only one reset signal and one main interrupt
line.
Please refer to below:
JHB100: reset-names = "stmmaceth";
Example usage of JHB100 in the device tree:
gmac0: ethernet@11b80000 {
compatible = "starfive,jhb100-dwmac",
"snps,dwmac-5.20";
interrupts = <225>;
interrupt-names = "macirq";
...
};
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 38bc34dc4f09..85cd3252e8b1 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -115,6 +115,7 @@ properties:
- sophgo,sg2044-dwmac
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
- tesla,fsd-ethqos
- thead,th1520-gmac
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 0d1962980f57..edc246a71ce3 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -18,6 +18,7 @@ select:
enum:
- starfive,jh7100-dwmac
- starfive,jh7110-dwmac
+ - starfive,jhb100-dwmac
required:
- compatible
@@ -30,6 +31,9 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jhb100-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -122,6 +126,25 @@ allOf:
reset-names:
minItems: 2
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jhb100-dwmac
+ then:
+ properties:
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: macirq
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+
unevaluatedProperties: false
examples:
--
2.17.1
^ permalink raw reply related
* [net-next v1 v1 3/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
JHB100 SGMII interface tx/rx mac clock is split and require to
set clock rate in 10M/100M/1000M speed. So dts need to add a
new rx clock in code, dts and dt binding doc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 42 ++++++++++++++++---
1 file changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index edc246a71ce3..847d67a2c1d5 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -39,20 +39,26 @@ properties:
maxItems: 1
clocks:
+ minItems: 5
items:
- description: GMAC main clock
- description: GMAC AHB clock
- description: PTP clock
- description: TX clock
- description: GTX clock
+ - description: SGMII RX clock
clock-names:
- items:
- - const: stmmaceth
- - const: pclk
- - const: ptp_ref
- - const: tx
- - const: gtx
+ minItems: 5
+ maxItems: 6
+ contains:
+ enum:
+ - stmmaceth
+ - pclk
+ - ptp_ref
+ - tx
+ - gtx
+ - rx
starfive,tx-use-rgmii-clk:
description:
@@ -99,6 +105,14 @@ allOf:
minItems: 2
maxItems: 2
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
maxItems: 1
@@ -120,6 +134,14 @@ allOf:
minItems: 3
maxItems: 3
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
resets:
minItems: 2
@@ -139,6 +161,14 @@ allOf:
interrupt-names:
const: macirq
+ clocks:
+ minItems: 5
+ maxItems: 6
+
+ clock-names:
+ minItems: 5
+ maxItems: 6
+
resets:
maxItems: 1
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net v2] ppp: require CAP_NET_ADMIN in target netns for unattached ioctls
From: Qingfang Deng @ 2026-04-08 8:45 UTC (permalink / raw)
To: Taegu Ha; +Cc: linux-ppp, gnault, jaco, richardbgobert, ericwouds, netdev
In-Reply-To: <20260408065109.2171-1-hataegu0826@gmail.com>
Hi, Taegu
Please wait at least 24 hours before posting a new patch to netdev. See
https://docs.kernel.org/process/maintainer-netdev.html for more information.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
From: Petr Oros @ 2026-04-08 8:54 UTC (permalink / raw)
To: Rinitha, SX, netdev@vger.kernel.org
Cc: Vecera, Ivan, Kitszel, Przemyslaw, Eric Dumazet,
Kubalewski, Arkadiusz, Andrew Lunn, Nguyen, Anthony L,
Simon Horman, intel-wired-lan@lists.osuosl.org, Jakub Kicinski,
Paolo Abeni, David S. Miller, linux-kernel@vger.kernel.org
In-Reply-To: <IA1PR11MB6241B58FF425A8684CFAE7A28B50A@IA1PR11MB6241.namprd11.prod.outlook.com>
On 4/1/26 18:29, Rinitha, SX wrote:
>> -----Original Message-----
>> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
>> Sent: 13 February 2026 19:47
>> To: netdev@vger.kernel.org
>> Cc: Vecera, Ivan <ivecera@redhat.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Eric Dumazet <edumazet@google.com>; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Simon Horman <horms@kernel.org>; intel-wired-lan@lists.osuosl.org; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; linux-kernel@vger.kernel.org
>> Subject: [Intel-wired-lan] [PATCH net] ice: fix missing SMA pin initialization in DPLL subsystem
>>
>> The DPLL SMA/U.FL pin redesign introduced ice_dpll_sw_pin_frequency_get() which gates frequency reporting on the pin's active flag. This flag is determined by ice_dpll_sw_pins_update() from the PCA9575 GPIO expander state. Before the redesign, SMA pins were exposed as direct HW input/output pins and ice_dpll_frequency_get() returned the CGU frequency unconditionally — the PCA9575 state was never consulted.
>>
>> The PCA9575 powers on with all outputs high, setting ICE_SMA1_DIR_EN, ICE_SMA1_TX_EN, ICE_SMA2_DIR_EN and ICE_SMA2_TX_EN. Nothing in the driver writes the register during initialization, so
>> ice_dpll_sw_pins_update() sees all pins as inactive and
>> ice_dpll_sw_pin_frequency_get() permanently returns 0 Hz for every SW pin.
>>
>> Fix this by writing a default SMA configuration in
>> ice_dpll_init_info_sw_pins(): clear all SMA bits, then set SMA1 and
>> SMA2 as active inputs (DIR_EN=0) with U.FL1 output and U.FL2 input disabled. Each SMA/U.FL pair shares a physical signal path so only one pin per pair can be active at a time. U.FL pins still report frequency 0 after this fix: U.FL1 (output-only) is disabled by ICE_SMA1_TX_EN which keeps the TX output buffer off, and U.FL2
>> (input-only) is disabled by ICE_SMA2_UFL2_RX_DIS. They can be activated by changing the corresponding SMA pin direction via dpll netlink.
>>
>> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
>> Signed-off-by: Petr Oros <poros@redhat.com>
>> ---
>> drivers/net/ethernet/intel/ice/ice_dpll.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
> When SMA1 is changed from output to input , U.FL1 (input) is expected to get connected but is still disconnected
> Similary, when SMA2 is changed from input to output , U.FL2 (output) is still disconnected
Hi Rinitha,
Thanks for testing this.
The initialization patch itself is correct. After boot, the PCA9575
register is written to a known-good default state and SMA1/SMA2
properly report as active inputs with the expected frequency.
The behavior you describe (U.FL1/U.FL2 staying disconnected after
SMA direction change) is a pre-existing issue in
ice_dpll_sma_direction_set(), not in the initialization path.
I am addressing this in v2 of "[PATCH iwl-net] ice: fix U.FL pin
state set affecting paired SMA pin" with an expanded scope that
covers both directions of the SMA/U.FL pairing.
Is it OK like this?
Regards,
Petr
^ permalink raw reply
* Re: [PATCH net] net_sched: fix skb memory leak in deferred qdisc drops
From: Eric Dumazet @ 2026-04-08 8:54 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, davem, Damilola Bello
In-Reply-To: <80b74501-5c15-4b69-a825-b747ac509855@suse.de>
On Tue, Apr 7, 2026 at 10:14 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
>
>
> On 4/7/26 7:02 PM, Fernando Fernandez Mancera wrote:
> > When the network stack cleans up the deferred list via qdisc_run_end(),
> > it operates on the root qdisc. If the root qdisc do not implement the
> > TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and
> > gets stranded on the child's local to_free list.
> >
> > Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It
> > fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If
> > the flag is present, the packet is appended directly to the root's
> > to_free list. Otherwise, drop it directly as it was done before the
> > optimization was implemented.
> >
> > Fixes: a6efc273ab82 ("net_sched: use qdisc_dequeue_drop() in cake, codel, fq_codel")
> > Reported-by: Damilola Bello <damilola@aterlo.com>
> > Closes: https://lore.kernel.org/netdev/CAPgFtOLaedBMU0f_BxV2bXftTJSmJr018Q5uozOo5vVo6b9tjw@mail.gmail.com/
> > Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> > ---
> > include/net/sch_generic.h | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> > index c3d657359a3d..61ba54e909f2 100644
> > --- a/include/net/sch_generic.h
> > +++ b/include/net/sch_generic.h
> > @@ -1170,12 +1170,18 @@ static inline void tcf_kfree_skb_list(struct sk_buff *skb)
> > static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff *skb,
> > enum skb_drop_reason reason)
> > {
> > + struct Qdisc *root = qdisc_root_sleeping(q);
> > +
> > DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
> > DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
> >
> > - tcf_set_drop_reason(skb, reason);
> > - skb->next = q->to_free;
> > - q->to_free = skb;
> > + if (root->flags & TCQ_F_DEQUEUE_DROPS) {
> > + tcf_set_drop_reason(skb, reason);
> > + skb->next = q->to_free;
> > + q->to_free = skb;
> > + } else {
> > + kfree_skb_reason(skb, reason);
> > + }
> > }
> >
>
> *sigh* this is missing the following diff - tested it but forgot to
> amend it. Anyway, Eric let me know what do you think, if you like this
> solution I can send the v2 appending the skb to the root's to_free list
> properly.
>
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index 61ba54e909f2..0e4166319c02 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -1177,8 +1177,8 @@ static inline void qdisc_dequeue_drop(struct Qdisc
> *q, struct sk_buff *skb,
>
> if (root->flags & TCQ_F_DEQUEUE_DROPS) {
> tcf_set_drop_reason(skb, reason);
> - skb->next = q->to_free;
> - q->to_free = skb;
> + skb->next = root->to_free;
> + root->to_free = skb;
> } else {
> kfree_skb_reason(skb, reason);
> }
>
Sure, please also use rcu_read_lock() before calling qdisc_root_sleeping()
^ permalink raw reply
* RE: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Wei Fang @ 2026-04-08 8:59 UTC (permalink / raw)
To: Jakub Kicinski, Vladimir Oltean
Cc: Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20260403011738.1795644-1-kuba@kernel.org>
> > +static int netc_init_switch_id(struct netc_switch *priv)
> > +{
> > + struct netc_switch_regs *regs = &priv->regs;
> > + struct dsa_switch *ds = priv->ds;
> > +
> > + /* The value of 0 is reserved for the VEPA switch and cannot
> > + * be used.
> > + */
> > + if (ds->index > SWCR_SWID || !ds->index) {
> > + dev_err(priv->dev, "Switch index %d out of range\n",
> > + ds->index);
> > + return -ERANGE;
> > + }
>
> Does this check cause the probe to fail unconditionally for standard
> single-switch topologies?
>
> The DSA core typically assigns ds->index = 0 by default for the first switch.
> Because !ds->index evaluates to true for index 0, this setup function will
> always fail unless the dsa,member property is explicitly overridden in the
> device tree.
As I mentioned in another mail, we added the 'dsa,member' property to the
netc switch DT-binding doc, specifying that the 'member' (switch index) value
cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> Could the driver translate the hardware ID internally, for example by writing
> ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> restriction onto the software DSA index?
The current approach is based on Vladimir's suggestion. I need to confirm with
Vladimir which approach is better.
Hi Vladimir,
What are your thoughts on this suggestion? Is this approach better?
>
> [ ... ]
> > + for_each_available_child_of_node_scoped(ports, child) {
> > + /* If the node does not have phy-handle property, then
> > + * the port does not connect to a PHY, so the port is
> > + * not the EMDIO consumer.
> > + */
> > + phy_node = of_parse_phandle(child, "phy-handle", 0);
> > + if (!phy_node)
> > + continue;
> > +
> > + if (!netc_port_is_emdio_consumer(child)) {
> > + of_node_put(phy_node);
> > + continue;
> > + }
> > +
> > + phydev = of_phy_find_device(phy_node);
> > + of_node_put(phy_node);
> > + if (!phydev) {
> > + err = -EPROBE_DEFER;
> > + goto out;
> > + }
>
> Could this logic cause an infinite probe deferral loop for ports sharing an
> internal MDIO bus?
>
> The netc_port_is_emdio_consumer() function assumes any port node without
> an
> mdio child is an EMDIO consumer waiting for an external controller. However,
> if multiple sibling ports on the same switch share a single internal MDIO bus
> defined under one port, the other ports will lack an mdio child node.
>
> This would cause those ports to be mistakenly treated as external EMDIO
> consumers, calling of_phy_find_device(). Because the internal MDIO bus is not
> registered until later in netc_setup(), the PHY device cannot be found, and
> the driver returns -EPROBE_DEFER.
>
> Since netc_setup() is never reached, the MDIO bus is never registered,
> causing an infinite deferral loop. Could the driver more accurately identify
> whether the PHY belongs to its own switch before deferring?
This case will not be true, from the hardware perspective, the switch ports
do not support share a single internal MDIO bus defined under one port.
The internal MDIO bus of a port can only access its own external PHY. So
a switch port must either use EMDIO to access its PHY or its internal MDIO
bus to access its PHY.
>
> > +
> > + put_device(&phydev->mdio.dev);
> > + }
> > +
> > +out:
> > + of_node_put(ports);
> > +
> > + return err;
> > +}
> > +
> > +static int netc_switch_pci_init(struct pci_dev *pdev)
> > +{
> [ ... ]
> > + regs->base = pci_ioremap_bar(pdev, NETC_REGS_BAR);
> > + if (!regs->base) {
> > + err = -ENXIO;
> > + dev_err(dev, "pci_ioremap_bar() failed\n");
> > + goto release_mem_regions;
> > + }
> [ ... ]
> > +static void netc_switch_pci_destroy(struct pci_dev *pdev)
> > +{
> > + struct netc_switch *priv = pci_get_drvdata(pdev);
> > +
> > + iounmap(priv->regs.base);
> > + pci_release_mem_regions(pdev);
> > + pci_disable_device(pdev);
> > +}
>
> Does unmapping the memory here introduce a use-after-unmap issue when the
> MDIO bus is unregistered?
>
> The driver registers the MDIO bus using devm_of_mdiobus_register(), meaning
> devres cleans it up asynchronously after the remove function returns or when
> probe fails.
>
> However, in netc_switch_pci_destroy(), the driver explicitly unmaps the PCI
> I/O memory via iounmap(). Since netc_switch_pci_destroy() is called
> synchronously inside the remove function and probe error paths, the memory is
> unmapped before the MDIO bus is unregistered by devres.
>
> When devres eventually unregisters the MDIO bus, it detaches PHY devices,
> which often perform MDIO transactions during removal. Because the
> underlying
> memory priv->regs.base is already unmapped, these MDIO read/write callbacks
> could trigger a synchronous external abort or kernel panic.
>
> Would it be better to use pcim_iomap() to tie the memory mapping lifecycle to
> devres, ensuring it outlives the MDIO bus?
Great, I will pcim_iomap().
^ permalink raw reply
* [net-next v1 v1 0/5] Add StarFive JHB100 soc SGMII GMAC support
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
JHB100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
Managent Controller). Similar with Aspeed 27x0.
The JHB100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
JHB100 GMAC still using designware GMAC core like JH7100 and JH7110,
and contains 2 SGMII interfaces, 1 RGMII/RMII interface, 1 RMII
interface. In JH7100/JH7110 dwmac-starfive.c have supported RGMII/RMII
interface. So require to add SGMII support to dwmac-starfive.c for JHB100.
SGMII serdes PHY has been intergrated in JHB100 and do not have driver
setting.
In JHB100 EVB board, SGMII connect with motorcomm YT8531s external PHY
and support RJ45 ethernet port.
The patch base in 7.0-rc5
Minda Chen (5):
dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 sgmii rx clk
net: stmmac: starfive: Add JHB100 SGMII interface
net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
.../devicetree/bindings/net/snps,dwmac.yaml | 1 +
.../bindings/net/starfive,jh7110-dwmac.yaml | 89 +++++++++++++------
.../ethernet/stmicro/stmmac/dwmac-starfive.c | 38 +++++++-
3 files changed, 98 insertions(+), 30 deletions(-)
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.17.1
^ permalink raw reply
* [net-next v1 v1 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Minda Chen @ 2026-04-08 8:44 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260408084416.29753-1-minda.chen@starfivetech.com>
Add default disable split header flag in all the starfive
soc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index df7b2fc9989d..f6e5a2c4dc27 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -143,7 +143,7 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
}
dwmac->dev = &pdev->dev;
- plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+ plat_dat->flags |= (STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | STMMAC_FLAG_SPH_DISABLE);
plat_dat->bsp_priv = dwmac;
plat_dat->dma_cfg->dche = true;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v5 00/10] Decouple receive and transmit enablement in team driver
From: Jiri Pirko @ 2026-04-08 9:00 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <CANkEMgn80UM7+mymVm21Q8yszgVeh029tvO+kHqmLGmf-2MU5g@mail.gmail.com>
Wed, Apr 08, 2026 at 02:12:35AM +0200, marcharvey@google.com wrote:
>On Tue, Apr 7, 2026 at 4:55 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Mon, Apr 06, 2026 at 05:03:36AM +0200, marcharvey@google.com wrote:
>> >Allow independent control over receive and transmit enablement states
>> >for aggregated ports in the team driver.
>> >
>> >The motivation is that IEE 802.3ad LACP "independent control" can't
>> >be implemented for the team driver currently. This was added to the
>> >bonding driver in commit 240fd405528b ("bonding: Add independent
>> >control state machine").
>> >
>> >This series also has a few patches that add tests to show that the old
>> >coupled enablement still works and that the new decoupled enablement
>> >works as intended (4, 5, and 10).
>> >
>> >There are three patches with small fixes as well, with the goal of
>> >making the final decoupling patch clearer (1, 2, and 3).
>>
>> Looks fine to me now. Do you have libteam/teamd counterpart?
>
>I don't see a need for this to be used in any of the teamd runners.
Why do you need this then?
^ permalink raw reply
* Re: [PATCH net-next v6 03/10] net: team: Rename port_disabled team mode op to port_tx_disabled
From: Jiri Pirko @ 2026-04-08 9:02 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260408-teaming-driver-internal-v6-3-e5bcdcf72504@google.com>
Wed, Apr 08, 2026 at 04:52:22AM +0200, marcharvey@google.com wrote:
>This team mode op is only used by the load balance mode, and it only
>uses it in the tx path.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox