* Re: [PATCH net-next] octeontx2-pf: add page pool ethtool statistics
From: Joe Damato @ 2026-06-15 20:32 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: linux-kernel, netdev, andrew+netdev, davem, edumazet, kuba,
pabeni, sgoutham
In-Reply-To: <20260615032141.521667-1-rkannoth@marvell.com>
On Mon, Jun 15, 2026 at 08:51:41AM +0530, Ratheesh Kannoth wrote:
> Expose page pool allocator statistics through ethtool.
> When the interface is up, aggregate stats from each
> receive queue page pool and append the common page_pool ethtool stat
> block to the driver's private statistics set.
>
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
> ---
> .../marvell/octeontx2/nic/otx2_ethtool.c | 35 +++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
Reviewed-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* Re: e1000e: Report link down after "Detected Hardware Unit Hang" ?
From: Helge Deller @ 2026-06-15 20:36 UTC (permalink / raw)
To: Andrew Lunn, Helge Deller
Cc: Tony Nguyen, Przemek Kitszel, intel-wired-lan, netdev
In-Reply-To: <e78576e0-9b55-446f-9d10-da3b7aec9b31@lunn.ch>
On 6/15/26 18:41, Andrew Lunn wrote:
> On Sun, Jun 14, 2026 at 11:48:08PM +0200, Helge Deller wrote:
>> I'm regularily facing the known "eno1: Detected Hardware Unit Hang:"
>> with my on-board intel e1000e NIC hardware.
>> Since none of he various tips on the internet helped, I had the idea
>> to setup a master/slave bond networking to fail over to another NIC when
>> the Intel chip hangs.
>>
>> Sadly this doesn't work as intended, because the link of the intel NIC
>> isn't reported "down", so the failover never happens, unless I manually
>> start "ifconfig eno1 down".
>>
>> My question: Shouldn't the intel NIC ideally report Link Down if we know
>> it hangs? That way a fail-over should at least happen, right?
>>
>> Below is a completely untested patch.
>> Does it make sense that I try to test and/or develop such a patch, or
>> are there things I miss?
>
> If the interface is dead, then setting the carrier down makes a lot of
> sense.
That's what I think as well. Thanks for confirming.
> One question i have is, what do you need to do to recover the
> hardware? Will it correctly set the carrier up when you do the
> recovery?
The only way I could recover was to plug the network cable and re-insert it.
I have not tested bringing the NIC down.
But in both cases the driver will need to re-detect the media & link
> Also, just looking at your proposed change, it is not clear to me why
> such an assignment will result in carrier down. It would be good to
> explain it in the commit message.
Sure. The patch I attached was completely untested and just based on
the analysis of the flow and how to make the Link possibly report to be down.
Maybe someone knowledgeable of the driver has a better suggestion how to
report the link down situation in a clean way?
Helge
^ permalink raw reply
* Re: [PATCH net v3 2/2] ipv6: account for fraggap on the paged allocation path
From: Jakub Kicinski @ 2026-06-15 20:39 UTC (permalink / raw)
To: Wongi Lee
Cc: netdev, David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, asml.silence, dhowells, willemb,
Jungwoo Lee
In-Reply-To: <aiq5VQknt1QHcvio@DESKTOP-19IMU7U.localdomain>
On Thu, 11 Jun 2026 22:34:13 +0900 Wongi Lee wrote:
> copy = datalen - transhdrlen - fraggap - pagedlen;
> - /* [!] NOTE: copy may be negative if pagedlen>0
> - * because then the equation may reduces to -fraggap.
> - */
> if (copy < 0 && !(flags & MSG_SPLICE_PAGES)) {
You remove the comment because copy can never be negative with
pagedlen>0 now, can we not remove "!(flags & MSG_SPLICE_PAGES)"
as well then?
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
From: Johan Alvarado @ 2026-06-15 20:41 UTC (permalink / raw)
To: maxime.chevallier, linusw, alsi, andrew, olteanv, davem, edumazet,
kuba, pabeni, netdev
Cc: linux, namiltd, luizluca, linux-kernel
In-Reply-To: <63983efb-dcad-4b34-9d35-4086de11be5e@bootlin.com>
> This comment implies that you could deal with SGMII aneg at some point.
> [...] makes me wonder if this whole SGMII/2500BaseX series should be
> represented as a PCS phylink driver.
Hi Maxime,
You're right, and I'll convert the SerDes path to a phylink_pcs for v4.
It splits the MAC and SerDes layers cleanly, drops the "ext then sds"
branches in mac_link_up/down, and makes future in-band aneg an additive
change instead of a rewrite.
One point I'd like to confirm on scope: I can only test the forced-link
path on my MR80X (fixed-link / conventional PHY), and I have no setup to
exercise SGMII in-band autonegotiation. My plan is to do the PCS refactor
keeping the link forced (outband / no in-band AN), and leave actual
in-band aneg support for a follow-up once I have hardware to validate it.
Does limiting v4 to the forced path sound acceptable, or would you prefer
in-band aneg implemented up front? I'd rather not add a code path I can't
test.
I'll also reword the misleading "disable in-band aneg" comment.
net-next being closed until the 29th gives me time to do this properly,
so v4 will carry the PCS conversion, retested on the MR80X v2.20.
Best regards,
Johan
^ permalink raw reply
* Re: [PATCH net-next v10 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Jakub Kicinski @ 2026-06-15 20:42 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
In-Reply-To: <ajBRwYftEol8IE49@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Mon, 15 Jun 2026 12:25:53 -0700 Dipayaan Roy wrote:
> Just a gentle ping on this series. The approach was agreed upon, and it
> has picked up a few Reviewed-by tags as well.
>
> Please let me know if you need anything else from me, or if I should
> resend it to collect the tags.
Don't recall now what the exact sequence was but pretty sure this
no longer applied after some other mana series was merged.
^ permalink raw reply
* Re: [PATCH v2 4/5] binder: Remove mmap_lock fallback
From: Carlos Llamas @ 2026-06-15 20:43 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Alice Ryhl, Andrew Morton, Arve Hjønnevåg,
Christian Brauner, David Ahern, David S. Miller,
Greg Kroah-Hartman, Liam R. Howlett, linux-mm, Lorenzo Stoakes,
netdev, Shakeel Butt, Suren Baghdasaryan, Todd Kjos,
Vlastimil Babka
In-Reply-To: <20260610230417.77D64DBB@davehans-spike.ostc.intel.com>
On Wed, Jun 10, 2026 at 04:04:17PM -0700, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> Previously, the per-VMA locking could fail in the face of writers
> which necessitate a fallback to mmap_lock. The new
> vma_start_read_unlocked() will wait for writers instead of failing.
>
> Use the new helper. Wait for writers. Remove the fallback to mmap_lock.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Acked-by: Lorenzo Stoakes <ljs@kernel.org>
> Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Shakeel Butt <shakeel.butt@linux.dev>
> Cc: linux-mm@kvack.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Arve Hjønnevåg <arve@android.com>
> Cc: Todd Kjos <tkjos@android.com>
> Cc: Christian Brauner <christian@brauner.io>
> Cc: Carlos Llamas <cmllamas@google.com>
> Cc: Alice Ryhl <aliceryhl@google.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: David Ahern <dsahern@kernel.org>
> Cc: netdev@vger.kernel.org
>
> ---
>
> b/drivers/android/binder_alloc.c | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff -puN drivers/android/binder_alloc.c~binder-vma-waiter drivers/android/binder_alloc.c
> --- a/drivers/android/binder_alloc.c~binder-vma-waiter 2026-06-10 15:57:56.419452721 -0700
> +++ b/drivers/android/binder_alloc.c 2026-06-10 15:57:56.423452863 -0700
> @@ -259,21 +259,14 @@ static int binder_page_insert(struct bin
> struct vm_area_struct *vma;
> int ret = -ESRCH;
>
> - /* attempt per-vma lock first */
> - vma = lock_vma_under_rcu(mm, addr);
> - if (vma) {
> - if (binder_alloc_is_mapped(alloc))
> - ret = vm_insert_page(vma, addr, page);
> - vma_end_read(vma);
> + vma = vma_start_read_unlocked(mm, addr);
> + if (!vma)
> return ret;
> - }
>
> - /* fall back to mmap_lock */
> - mmap_read_lock(mm);
> - vma = vma_lookup(mm, addr);
> - if (vma && binder_alloc_is_mapped(alloc))
> + if (binder_alloc_is_mapped(alloc))
> ret = vm_insert_page(vma, addr, page);
> - mmap_read_unlock(mm);
> +
> + vma_end_read(vma);
>
> return ret;
> }
> _
Thanks,
Acked-by: Carlos Llamas <cmllamas@google.com>
^ permalink raw reply
* Re: [PATCH net] netdev-genl: report NAPI thread PID in the caller's pid namespace
From: Joe Damato @ 2026-06-15 20:43 UTC (permalink / raw)
To: Maoyi Xie
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Daniel Borkmann, Nikolay Aleksandrov, David Wei,
Stanislav Fomichev, Dragos Tatulea, Samiullah Khawaja, netdev,
linux-kernel, stable
In-Reply-To: <20260615171736.1709318-1-maoyixie.tju@gmail.com>
On Tue, Jun 16, 2026 at 01:17:36AM +0800, Maoyi Xie wrote:
> netdev_nl_napi_fill_one() reports the NAPI kthread PID in NETDEV_A_NAPI_PID
> using task_pid_nr(), which returns the PID in the initial pid namespace.
>
> NETDEV_CMD_NAPI_GET does not have GENL_ADMIN_PERM and the netdev genl family
> is netnsok, so a caller in a child pid namespace can issue it. That caller
> then sees the kthread's global PID, even though the kthread is not visible
> in its pid namespace, where the value should be 0.
>
> Translate the PID through the caller's pid namespace, the same way commit
> 3799c2570982 ("io_uring/fdinfo: translate SqThread PID through caller's
> pid_ns") did for the io_uring SQPOLL thread. The doit and dumpit paths both
> run synchronously in the caller's context, so task_active_pid_ns(current) is
> the caller's pid namespace.
>
> Fixes: db4704f4e4df ("netdev-genl: Add PID for the NAPI thread")
> Cc: stable@vger.kernel.org
> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
> ---
> net/core/netdev-genl.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* Re: [BUG] FORTIFY: memcpy overflow in skb_tunnel_info_unclone() from geneve_xmit()
From: Ilya Maximets @ 2026-06-15 20:44 UTC (permalink / raw)
To: Kees Cook; +Cc: i.maximets, Johan Thomsen, netdev, dev
In-Reply-To: <202606101245.549180BC85@keescook>
On 6/10/26 9:51 PM, Kees Cook wrote:
> On Mon, Jun 08, 2026 at 11:41:37AM +0200, Ilya Maximets wrote:
>> On 6/8/26 10:25 AM, Johan Thomsen wrote:
>>> Hello,
>>>
>>> I am seeing what looks like a kernel bug in the Geneve/OVS/vhost
>>> transmit path on a Talos Linux node running Kube-ovn with Geneve
>>> overlay and KubeVirt VM traffic.
>>>
>>> Environment:
>>>
>>> Kernel: 6.18.33-talos
>>> Distro: Talos v1.13.3
>>>
>>> Compiler/config:
>>>
>>> CONFIG_CC_VERSION_TEXT="clang version 22.1.2"
>>> CONFIG_CC_IS_CLANG=y
>>> CONFIG_LTO=y
>>> CONFIG_LTO_CLANG=y
>>> CONFIG_LTO_CLANG_THIN=y
>>> CONFIG_FORTIFY_SOURCE=y
>>>
>>> Hardware: HPE ProLiant DL325 Gen11, AMD EPYC
>>>
>>> NIC driver: bnxt_en
>>>
>>> Workload/network:
>>>
>>> Kube-OVN, Geneve overlay
>>> Open vSwitch datapath
>>> KubeVirt/QEMU VM traffic via vhost/tap
>>>
>>> Relevant console output:
>>>
>>> [ 648.742603] memcpy: detected buffer overflow: 104 byte write of
>>> buffer size 96
>>> [ 648.749907] WARNING: CPU: 61 PID: 27020 at
>>> lib/string_helpers.c:1036 __fortify_report+0x45/0x60
>>> [ 648.758689] Modules linked in: dm_round_robin dm_multipath lpfc
>>> nvmet_fc nvmet intel_rapl_msr intel_rapl_common ahci nvme_auth bnxt_en
>>> nvme hpilo hkdf libahci sp5100_tco watchdog k10temp
>>> [ 648.775429] CPU: 61 UID: 107 PID: 27020 Comm: vhost-27002 Not
>>> tainted 6.18.29-talos #1 PREEMPT(none)
>>> [ 648.784735] Hardware name: HPE ProLiant DL325 Gen11/ProLiant DL325
>>> Gen11, BIOS 2.84 11/05/2025
>>> [ 648.890478] skb_tunnel_info_unclone+0x179/0x190
>>> [ 648.895152] geneve_xmit+0x7fe/0xe00
>>> [ 648.907240] dev_hard_start_xmit+0xa7/0x1f0
>>> [ 648.911479] __dev_queue_xmit+0x864/0xf40
>>> [ 648.919688] do_execute_actions+0x9b9/0x1be0
>>> [ 648.927727] ovs_execute_actions+0x58/0x170
>>> [ 648.931960] ovs_dp_process_packet+0xb1/0x1c0
>>> [ 648.936370] ovs_vport_receive+0x90/0x100
>>> [ 648.940428] netdev_frame_hook+0x146/0x1a0
>>> [ 648.954093] __netif_receive_skb+0x3f/0x160
>>> [ 648.958324] process_backlog+0x10c/0x210
>>> [ 648.962295] __napi_poll+0x2f/0x190
>>> [ 648.965832] net_rx_action+0x2e3/0x500
>>> [ 648.969632] handle_softirqs+0xe7/0x310
>>> [ 648.985387] tun_get_user+0x137e/0x1510
>>> [ 649.005878] handle_tx+0x41f/0xd30
>>> [ 649.029014] vhost_run_work_list+0x52/0x90
>>> [ 649.033162] vhost_task_fn+0xc2/0x140
>>> [ 649.064145] ---[ end trace 0000000000000000 ]---
>>> [ 649.068820] ------------[ cut here ]------------
>>> [ 649.073489] kernel BUG at lib/string_helpers.c:1043!
>>>
>>> I don't know whether this is a real overflow or a FORTIFY false-positive.
>>
>> Looks like a false-positive from the __counted_by fortification.
>>
>> I'd guess something like this would fit it:
>>
>> diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
>> index 1fc2fb03ce3f9..e51c3795da474 100644
>> --- a/include/net/dst_metadata.h
>> +++ b/include/net/dst_metadata.h
>> @@ -164,6 +164,7 @@ static inline struct metadata_dst *tun_dst_unclone(struct sk_buff *skb)
>> if (!new_md)
>> return ERR_PTR(-ENOMEM);
>>
>> + new_md->u.tun_info.options_len = md_size;
>> memcpy(&new_md->u.tun_info, &md_dst->u.tun_info,
>> sizeof(struct ip_tunnel_info) + md_size);
>
> Speaking to this solution, it also makes sense, but does look redundant
> to the memcpy that follows it. I wonder something more in between would
> be better (the memcpy isn't needed to copy a struct, either):
>
> new_md->u.tun_info = md_dst->u.tun_info;
I like this. memcpy is not needed for the base struct indeed.
> memcpy(new_md->u.tun_info.options, md_dst->u.tun_info.options,
> md_dst->u.tun_info.options_len);
But I'd keep the accessor function for the options pointer here, since
we have it, i.e. ip_tunnel_info_opts(&new_md->u.tun_info).
I'll run some tests with that and post a patch.
>
> Is this the only place in the kernel where a struct ip_tunnel_info is
> being copied? The above really looks like an open-coded helper. :)
On a quick look through the code, it seems like this is the only place
where the data is copied directly from one tun_info into another.
Other places either construct the structure to/from other places or apply
modifications. And so the ip_tunnel_info_opts_set() is suitable in those
cases, but not in here.
Best regards, Ilya Maximets.
^ permalink raw reply
* Re: [PATCH net-next] selftests/net/openvswitch: add SET action test
From: Aaron Conole @ 2026-06-15 20:45 UTC (permalink / raw)
To: Minxi Hou
Cc: netdev, echaudro, i.maximets, davem, edumazet, kuba, pabeni,
horms, shuah, dev, linux-kselftest
In-Reply-To: <20260612130503.311240-1-houminxi@gmail.com>
Minxi Hou <houminxi@gmail.com> writes:
> Add test_action_set exercising OVS_ACTION_ATTR_SET with an ipv4 dst
> rewrite. The test verifies the SET action in three steps: first
> confirm normal forwarding, then apply set(ipv4(dst=10.0.0.99)) to
> rewrite the destination to an address nobody owns and verify ping
> fails, then restore normal forwarding and verify connectivity
> recovers.
>
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
> ---
Reviewed-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next v5 05/15] net: ethernet: oa_tc6: Move constant definitions to header file
From: Jakub Kicinski @ 2026-06-15 20:55 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay
Cc: Selvamani.Rajagopal, Andrew Lunn, Piergiorgio Beruto,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, devicetree,
linux-doc, Jerry Ray
In-Reply-To: <20260614-s2500-mac-phy-support-v5-5-89874b72f725@onsemi.com>
On Sun, 14 Jun 2026 10:00:21 -0700 Selvamani Rajagopal via B4 Relay
wrote:
> To help other source files within the module share the
> constant definitions, they are moved to a header file.
>
> The memory map selector(MMS) values that are defined in
> in Table 6 of OPEN Alliance 10BASE-T1x Serial Interface
> specification and currently used are added.
If you're adding kdoc on functions the return value must be documented
(unless it's void of course):
Warning: drivers/net/ethernet/oa_tc6/oa_tc6_ptp.c:34 No description found for return value of 'oa_tc6_ptp_register'
Warning: drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c:143 function parameter 'stats' not described in 'oa_tc6_get_ts_stats'
Warning: drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c:185 No description found for return value of 'oa_tc6_get_ts_info'
Please note that net-next is closed during the merge window, please
wait with the repost per: https://netdev.bots.linux.dev/net-next.html
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
From: Jakub Kicinski @ 2026-06-15 20:56 UTC (permalink / raw)
To: Parvathi Pudi
Cc: andrew+netdev, davem, edumazet, pabeni, danishanwar, rogerq,
pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, vigneshr, praneeth,
srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260611123636.376577-4-parvathi@couthit.com>
On Thu, 11 Jun 2026 18:03:28 +0530 Parvathi Pudi wrote:
> From: Roger Quadros <rogerq@ti.com>
>
> In HSR and PRP modes each outgoing frame must be sent on both PRU slave
> ports.
>
> Previously the driver was writing the frame into each port's transmit queue
> independently after updating the tags resulting in performing two OCMC
> buffer copy operations.
>
> Frame duplicate offloading is implemented with a common shared queue
> between the two ports. The driver writes the frame once into OCMC RAM,
> each port reads from the shared queue and replicates the transmission to
> both PRU ports, synchronising between PRU ports are maintained within
> firmware with appropriate handling.
>
> For HSR the driver inspects the encapsulated ethertype in the HSR tag.
> PTP frames (ETH_P_1588) are sent on the directed port only to avoid double
> duplication and all other HSR frames are duplicated to both ports.
> VLAN-tagged HSR frames are handled by advancing past the 4-byte VLAN header
> before reading the HSR tag.
>
> For PRP the driver checks the 6-byte RCT trailer for the ETH_P_PRP suffix
> to identify redundancy-tagged frames. Frames without an RCT are sent on the
> originating port only.
Warning: drivers/net/ethernet/ti/icssm/icssm_prueth.h:113 struct member 'host_recv_flag' not described in 'prueth_packet_info'
Please note that net-next will be closed for the next two weeks.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 09/15] bnxt_en: Add infrastructure for crypto key context IDs
From: Jakub Kicinski @ 2026-06-15 20:57 UTC (permalink / raw)
To: Michael Chan
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260614072407.2761092-10-michael.chan@broadcom.com>
On Sun, 14 Jun 2026 00:24:01 -0700 Michael Chan wrote:
> Each kTLS connection requires a crypto key context ID (KID). These KIDs
> are allocated from the firmware in batches. Add data structure to store
> these IDs. The bnxt_kid_info structure stores a batch of IDs and it can be
> linked as we allocate more batches. There is a bitmap in the structure
> to keep track of which ones are in use. Add APIs to allocate and free
> these KIDs.
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:283:7: warning: variable 'kctx_tx' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
283 | if (retry_cnt++ > KTLS_RETRY_MAX) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:319:8: note: uninitialized use occurs here
319 | kfree(kctx_tx);
| ^~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:283:3: note: remove the 'if' if its condition is always false
283 | if (retry_cnt++ > KTLS_RETRY_MAX) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
284 | atomic64_inc(&ktls->counters[BNXT_KTLS_ERR_RETRY_EXCEEDED]);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
285 | netdev_warn(dev, "%s timed out waiting for device, state %lx\n",
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
286 | __func__, bp->state);
| ~~~~~~~~~~~~~~~~~~~~~
287 | goto free;
| ~~~~~~~~~~
288 | }
| ~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:277:7: warning: variable 'kctx_tx' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
277 | if (!netif_running(dev) ||
| ^~~~~~~~~~~~~~~~~~~~~~
278 | test_bit(BNXT_STATE_IN_FW_RESET, &bp->state))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:319:8: note: uninitialized use occurs here
319 | kfree(kctx_tx);
| ^~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:277:3: note: remove the 'if' if its condition is always false
277 | if (!netif_running(dev) ||
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
278 | test_bit(BNXT_STATE_IN_FW_RESET, &bp->state))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
279 | goto free;
| ~~~~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:277:7: warning: variable 'kctx_tx' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized]
277 | if (!netif_running(dev) ||
| ^~~~~~~~~~~~~~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:319:8: note: uninitialized use occurs here
319 | kfree(kctx_tx);
| ^~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:277:7: note: remove the '||' if its condition is always false
277 | if (!netif_running(dev) ||
| ^~~~~~~~~~~~~~~~~~~~~~
../drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:260:42: note: initialize the variable 'kctx_tx' to silence this warning
260 | struct bnxt_ktls_offload_ctx_tx *kctx_tx;
| ^
| = NULL
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 12/15] bnxt_en: Support kTLS TX offload by implementing .tls_dev_add/del()
From: Jakub Kicinski @ 2026-06-15 20:58 UTC (permalink / raw)
To: Michael Chan
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260614072407.2761092-13-michael.chan@broadcom.com>
On Sun, 14 Jun 2026 00:24:04 -0700 Michael Chan wrote:
> Add basic infrastructure to allocate and free kTLS context IDs (KIDs)
> to support kTLS TX offload. To offload a connection in .tls_dev_add(),
> the first step is to allocate a KID. After that the kTLS offload
> command is sent to the HW via MPC using the function
> bnxt_xmit_crypto_cmd() introduced in the last patch.
>
> In .tls_dev_del(), we send the delete command to the HW using the
> same bnxt_xmit_crypto_cmd(). After that we free the KID, making it
> available for new offload. There is extra logic to handle ifdown,
> FW reset, and device reconfiguration while deleting the connection.
>
> bnxt_ktls_init() assigns bnxt_ktls_ops to the netdev and sets up
> the TLS TX offload feature. bnxt_ktls_init() will be called in
> the next patch.
Warning: drivers/net/ethernet/broadcom/bnxt/bnxt_crypto.c:320 expecting prototype for bnxt_free_one_ctx(). Prototype was for bnxt_free_one_kctx() instead
^ permalink raw reply
* Re: [PATCH net v2] psample: use nla_reserve() for PSAMPLE_ATTR_DATA
From: Jakub Kicinski @ 2026-06-15 21:08 UTC (permalink / raw)
To: Xiang Mei; +Cc: netdev, davem, yotam.gi, edumazet, pabeni, horms, bestswngs
In-Reply-To: <20260614034919.918494-1-xmei5@asu.edu>
On Sat, 13 Jun 2026 20:49:19 -0700 Xiang Mei wrote:
> psample_sample_packet() open-codes the PSAMPLE_ATTR_DATA attribute and
> reserves nla_total_size(data_len) bytes but only writes NLA_HDRLEN +
> data_len of them. When data_len is not a multiple of 4 the trailing
> alignment padding is left uninitialised, leaking stale slab memory to
> every listener on the PSAMPLE_NL_MCGRP_SAMPLE multicast group.
>
> Use nla_reserve(), which lays out the header and zeroes the padding, and
> copy the payload into the reserved area with skb_copy_bits().
Use the diff I provided or I will post it myself.
^ permalink raw reply
* Re: [PATCH net-next] selftests/net/openvswitch: add output truncation test
From: Jakub Kicinski @ 2026-06-15 21:17 UTC (permalink / raw)
To: Minxi Hou
Cc: netdev, aconole, echaudro, i.maximets, davem, edumazet, pabeni,
horms, shuah, dev, linux-kselftest
In-Reply-To: <20260611162537.3082686-1-houminxi@gmail.com>
On Fri, 12 Jun 2026 00:25:37 +0800 Minxi Hou wrote:
> Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test
> verifies truncation in three steps: first confirm normal forwarding
> works, then apply trunc(14) which truncates packets to the Ethernet
> header and verify ping fails, then restore normal forwarding and
> verify connectivity recovers.
>
> The trunc action sets OVS_CB(skb)->cutlen, causing pskb_trim at
> output time. With trunc(14) the IP payload is stripped, so the
> receiver drops the frame and ICMP echo reply is never generated.
Does not apply.
Please note that net-next is closed for the duration of the merge
window so you'll have to wait 2 weeks with the repost.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Jakub Kicinski @ 2026-06-15 21:17 UTC (permalink / raw)
To: Minxi Hou
Cc: netdev, aconole, echaudro, i.maximets, davem, edumazet, pabeni,
horms, shuah, dev, linux-kselftest
In-Reply-To: <20260615090507.3647256-1-houminxi@gmail.com>
On Mon, 15 Jun 2026 17:05:07 +0800 Minxi Hou wrote:
> Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that
> icmpv6(type=...) can be used in flow specifications. Without this
> registration the parser silently drops the token and the kernel
> rejects the flow with EINVAL because the expected ICMPv6 key
> attribute is missing.
net-next is closed
--
pw-bot: defer
^ permalink raw reply
* Re: [PATCH net-next 01/11] ipvs: Replace use of system_unbound_wq with system_dfl_long_wq
From: patchwork-bot+netdevbpf @ 2026-06-15 21:20 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260614114605.474783-2-pablo@netfilter.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Pablo Neira Ayuso <pablo@netfilter.org>:
On Sun, 14 Jun 2026 13:45:55 +0200 you wrote:
> From: Marco Crivellari <marco.crivellari@suse.com>
>
> This patch continues the effort to refactor workqueue APIs, which has
> begun with the changes introducing new workqueues and a new
> alloc_workqueue flag:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> [...]
Here is the summary with links:
- [net-next,01/11] ipvs: Replace use of system_unbound_wq with system_dfl_long_wq
https://git.kernel.org/netdev/net-next/c/30877f3da910
- [net-next,02/11] netfilter: nf_tables: use DEBUG_NET_WARN_ON_ONCE in packet and control paths
https://git.kernel.org/netdev/net-next/c/42eb1ca711b6
- [net-next,03/11] netfilter: nf_conncount: callers must hold rcu read lock
https://git.kernel.org/netdev/net-next/c/64d7d5abe216
- [net-next,04/11] netfilter: nf_conncount: use per nf_conncount_data spinlocks
https://git.kernel.org/netdev/net-next/c/eae341ecfc24
- [net-next,05/11] netfilter: nf_conncount: split count_tree_node rbtree walk into helper
https://git.kernel.org/netdev/net-next/c/2e064ae85942
- [net-next,06/11] netfilter: nf_conncount: add sequence counter to detect tree modifications
https://git.kernel.org/netdev/net-next/c/635a10f6d076
- [net-next,07/11] netfilter: nf_conncount: gc and rcu fixes
https://git.kernel.org/netdev/net-next/c/4eb7c3db5b85
- [net-next,08/11] netfilter: conntrack: check NULL when retrieving ct extension
https://git.kernel.org/netdev/net-next/c/e3cd138e5607
- [net-next,09/11] netfilter: flowtable: bail out if forward path cannot be discovered
https://git.kernel.org/netdev/net-next/c/871df5007eda
- [net-next,10/11] ipvs: fix doc syntax for conn_max sysctl
https://git.kernel.org/netdev/net-next/c/0e2a5d02f1d1
- [net-next,11/11] netfilter: nf_dup_netdev: add nf_dev_xmit_recursion*() helpers and use them
https://git.kernel.org/netdev/net-next/c/2354e975932d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v11 0/2] net: sfp: extend SMBus support
From: patchwork-bot+netdevbpf @ 2026-06-15 21:20 UTC (permalink / raw)
To: Jonas Jelonek
Cc: linux, andrew, hkallweit1, davem, edumazet, kuba, pabeni,
maxime.chevallier, netdev, linux-kernel, bjorn, horms
In-Reply-To: <20260614133418.2068201-1-jelonek.jonas@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 14 Jun 2026 13:34:16 +0000 you wrote:
> Today, the SFP driver only drives I2C adapters that advertise full
> I2C_FUNC_I2C, or SMBus-only adapters via single-byte transfers (with
> hwmon disabled). Several SoCs ship I2C/SMBus-only controllers that
> support more than just byte access -- e.g. word and I2C block -- and
> have SFP cages wired to them. Today, those adapters either work
> poorly or not at all.
>
> [...]
Here is the summary with links:
- [net-next,v11,1/2] net: sfp: apply I2C adapter quirks to limit block size
https://git.kernel.org/netdev/net-next/c/f2a138abfb71
- [net-next,v11,2/2] net: sfp: extend SMBus support
https://git.kernel.org/netdev/net-next/c/58b29bdf6186
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] selftests/net/openvswitch: add SET action test
From: patchwork-bot+netdevbpf @ 2026-06-15 21:20 UTC (permalink / raw)
To: Minxi Hou
Cc: netdev, aconole, echaudro, i.maximets, davem, edumazet, kuba,
pabeni, horms, shuah, dev, linux-kselftest
In-Reply-To: <20260612130503.311240-1-houminxi@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 12 Jun 2026 21:05:03 +0800 you wrote:
> Add test_action_set exercising OVS_ACTION_ATTR_SET with an ipv4 dst
> rewrite. The test verifies the SET action in three steps: first
> confirm normal forwarding, then apply set(ipv4(dst=10.0.0.99)) to
> rewrite the destination to an address nobody owns and verify ping
> fails, then restore normal forwarding and verify connectivity
> recovers.
>
> [...]
Here is the summary with links:
- [net-next] selftests/net/openvswitch: add SET action test
https://git.kernel.org/netdev/net-next/c/3b165c2a29cf
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: correcting section tags for .init and .exit data/functions
From: Rong Xu @ 2026-06-15 21:26 UTC (permalink / raw)
To: Nathan Chancellor
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Neal Cardwell, Kuniyuki Iwashima, Willem de Bruijn,
David Ahern, Ido Schimmel, Andreas Färber,
Manivannan Sadhasivam, Nick Desaulniers, Bill Wendling,
Justin Stitt, Maciej Żenczykowski, Yue Haibing, Jeff Layton,
Kees Cook, Fernando Fernandez Mancera, Gustavo A. R. Silva,
Sabrina Dubroca, Masahiro Yamada, Nicolas Schier, netdev,
linux-kernel, linux-arm-kernel, linux-actions, llvm,
kernel test robot
In-Reply-To: <20260613170143.GB3152432@ax162>
After studying the warnings further, I believe this is an incorrect fix.
Normally, *_net_ops structures are intended to live in .data (permanent memory),
even though they point to .init.text. Modpost is handling this by using
hardcoded whitelists to allow these specific exceptions. However, this
whitelist is
failing in ThinLTO because ThinLTO renames *_net_ops to *_net_ops.llvm.*.
I am withdrawing this patch and will send a fix to modpost instead.
Thanks,
-Rong
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: pse-pd: add bindings for Realtek/Broadcom PSE MCU
From: Rob Herring @ 2026-06-15 21:29 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Oleksij Rempel, Kory Maincent, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260612132944.460646-2-jelonek.jonas@gmail.com>
On Fri, Jun 12, 2026 at 01:29:41PM +0000, Jonas Jelonek wrote:
> Add a binding for the microcontroller (MCU) that fronts the PSE silicon
> on a range of managed switches. The host talks only to the MCU, over
> I2C/SMBus or UART, using a fixed message-based protocol; the PSE chips
> behind it never appear on the bus.
>
> The compatible identifies the PSE-MCU protocol dialect
> (realtek,pse-mcu-rtk or realtek,pse-mcu-bcm), not a specific part: the
> node describes the MCU - whose silicon is a general-purpose
> microcontroller that varies across boards - and the 'realtek' vendor
> prefix reflects the platform these MCUs are found on (Realtek-based PoE
> switches), following the google,cros-ec-* pattern rather than naming the
> MCU silicon. The '-rtk'/'-bcm' suffix selects the Realtek or Broadcom
> dialect within that one family. The specific PSE chip is detected at
> runtime and is not described here.
>
> A single compatible per dialect covers both the I2C/SMBus and UART
> attachments: the wire protocol is identical across them and the transport
> is expressed by the node's parent bus, so it is not encoded in the
> compatible.
>
> Both dialects share one protocol family and one device tree contract, so
> they are documented in a single binding under one vendor prefix. The
> 'realtek' prefix is used because this MCU front-end is found almost
> exclusively on Realtek-based switches; the Broadcom dialect is expressed
> as the realtek,pse-mcu-bcm compatible within the same family.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
> ---
> .../bindings/net/pse-pd/realtek,pse-mcu.yaml | 154 ++++++++++++++++++
> 1 file changed, 154 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml b/Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
> new file mode 100644
> index 000000000000..2fb729dcb41f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/pse-pd/realtek,pse-mcu.yaml
> @@ -0,0 +1,154 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/pse-pd/realtek,pse-mcu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek/Broadcom PSE MCU
> +
> +maintainers:
> + - Jonas Jelonek <jelonek.jonas@gmail.com>
> +
> +description: |
> + Microcontroller (MCU) that fronts the PSE hardware on switches using
> + Realtek (RTL8238B, RTL8239, RTL8239C) or Broadcom (BCM59111, BCM59121)
> + PSE chips. The MCU exposes a small message-based protocol over either
> + I2C/SMBus or UART; the actual PSE silicon is not accessed directly. The
> + Realtek and Broadcom variants share this device tree contract but use
> + different protocol opcodes, selected by the compatible.
> +
> + The compatible identifies the PSE-MCU protocol dialect, not a specific
> + part. The device described here is the MCU, whose own silicon varies
> + across boards and is incidental to the protocol. The MCU is not
> + made by Realtek or Broadcom; the 'realtek' vendor prefix reflects the
> + platform these MCUs are found on (Realtek-based PoE switches) and the
> + '-rtk'/'-bcm' suffix selects the Realtek or Broadcom protocol dialect.
> + The specific PSE chip behind the MCU is not described in the device
> + tree either; it is detected at runtime by querying the MCU.
> +
> + A single compatible per dialect covers both the I2C/SMBus and UART
> + attachments: the wire protocol is identical across them and the
> + transport is already expressed by the node's parent bus, so it is not
> + encoded in the compatible. Transport-specific properties differ
> + accordingly - the I2C attachment carries 'reg' (and, for Realtek,
> + 'realtek,i2c-protocol'), while the UART attachment carries the serial
> + peripheral properties such as 'current-speed'.
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,pse-mcu-rtk
The "rtk" feels redundant.
> + - realtek,pse-mcu-bcm
"brcm" is the standard vendor prefix, so use that instead of "bcm".
Though who defined the protocol in this case? Realtek or Broadcom? In
the latter case, I'd argue that "brcm" should be the vendor prefix.
> +
> + reg:
> + maxItems: 1
> +
> + power-supply:
> + description: Regulator supplying the PoE power rail.
> +
> + enable-gpios:
> + maxItems: 1
> +
> + realtek,i2c-protocol:
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [ i2c, smbus ]
> + description: |
> + Wire framing the MCU firmware expects on the I2C bus. "smbus" means
> + reads carry a leading command byte (0x00) and a repeated start; "i2c"
> + means bare 12-byte writes and reads with no command prefix. Only
> + applies to the Realtek I2C attachment.
I tend to think this should be distinguished by the compatible string.
That would simplify the schema given it only applies to one of the
compatible strings.
Rob
^ permalink raw reply
* Re: [PATCH net v2] psample: use nla_reserve() for PSAMPLE_ATTR_DATA
From: Xiang Mei @ 2026-06-15 21:48 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, yotam.gi, edumazet, pabeni, horms, bestswngs
In-Reply-To: <20260615140815.7543fd29@kernel.org>
On Mon, Jun 15, 2026 at 2:08 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sat, 13 Jun 2026 20:49:19 -0700 Xiang Mei wrote:
> > psample_sample_packet() open-codes the PSAMPLE_ATTR_DATA attribute and
> > reserves nla_total_size(data_len) bytes but only writes NLA_HDRLEN +
> > data_len of them. When data_len is not a multiple of 4 the trailing
> > alignment padding is left uninitialised, leaking stale slab memory to
> > every listener on the PSAMPLE_NL_MCGRP_SAMPLE multicast group.
> >
> > Use nla_reserve(), which lays out the header and zeroes the padding, and
> > copy the payload into the reserved area with skb_copy_bits().
>
> Use the diff I provided or I will post it myself.
You can post it yourself. Thank you for taking the time to deliver
that patch. I don't want to take credit for your work.
Xiang
^ permalink raw reply
* [PATCH net-next v5 0/6] pds_core: Add PLDM firmware update and host backed memory support
From: Nikhil P. Rao @ 2026-06-15 21:49 UTC (permalink / raw)
To: netdev
Cc: kuba, brett.creeley, eric.joyner, andrew+netdev, davem, edumazet,
pabeni, jacob.e.keller, Nikhil P. Rao
This series adds PLDM-based firmware update support to the pds_core
driver. PLDM (Platform Level Data Model) is a DMTF standard for firmware
management that provides a vendor-neutral interface for firmware updates.
The implementation uses the kernel's pldmfw library for package parsing
and component matching. Users can update entire firmware packages or
individual components via devlink flash. Component information is
displayed via devlink info, showing firmware versions and update status
for each component.
The series also adds host backed memory support, allowing firmware to
request memory pages from the host for its operations.
Changes since v4 (sashiko review, Simon Horman):
- Invalidate cached component info in recovery path to ensure stale
versions are not reported after firmware changes
- Fix v1 error handling: propagate errors from pdsc_dl_fw_list_info_get()
instead of masking them
- Fix v2 error handling: fall back to dev_info.fw_version only when
pdsc_get_component_info() fails; propagate devlink errors so partial
replies are discarded
- Clean up max_fw_slots comment to clarify it contains component count
Changes since v3:
- Changed "fw.mainfw" to just "fw" for main firmware (Jakub Kicinski).
Gold slot main firmware is reported as "fw.gold".
- Removed redundant memset before alloc_pages (Paolo Abeni)
- Changed dev_err to dev_warn for alloc_pages failure (Paolo Abeni)
- Only report dev_info.fw_version for identity version 1 (version 2+
reports firmware via PLDM component info)
- Fixed checkpatch alignment issue by extracting pdsc_dl_info_get_v1()
helper function
Changes since v2:
- Use driver-defined component names instead of passing through firmware
names (Jakub Kicinski). Added component_type enum that firmware populates,
driver maps to stable names like fw.mainfw, fw.goldfw, fw.bootloader.
Added documentation of firmware version names to pds_core.rst.
- Fixed bugs identified by sashiko:
Patch 2 (identity version 2):
- Fix comment using wrong macro names (IDENTIFY vs IDENTITY)
Patch 3 (PLDM firmware update):
- DMA-after-free on EAGAIN/ETIMEDOUT: when a command times out or
returns busy, firmware may still be accessing the DMA buffer; defer
freeing until a subsequent command succeeds
- Use dev_warn_once for incompatible firmware version (ver==0)
- Clear component cache after flash to show updated versions
Patch 4 (component info):
- Fix min_t(u8) truncation of max_fw_slots (u16) to min_t(u16)
- Fix F_FIXED early return skipping F_RUNNING flag check
- Don't fail devlink info if component query fails; use dev_warn_once
and continue to report generic fields (fw, asic.id, serial_number)
Patch 5 (host backed memory):
- Switch from adminq to devcmd; fixes both workqueue self-deadlock
during recovery (adminq completion runs on same wq as health_thread)
and health_work re-queued after cancel (adminq timeout re-queues work)
- Remove MEM_DEL from teardown path; fixes both MEM_DEL sent twice
for same tag and num_host_mem_reqs ambiguous semantics (now only
tracks pages to free). pci_clear_master guarantees DMA quiescence.
- Fix PDSC_HOST_MEM_MAX_CONTIG to 4MB constant (was arch-dependent)
- Not fixed: pdsc_host_mem_add() failure ignored; partial host memory
is acceptable and firmware handles fewer regions than requested
Patch 6 (debugfs):
- Move pdsc_debugfs_del_host_mem() before pdsc_host_mem_free() to
fix use-after-free race with debugfs readers
- Use %u for unsigned types and %pad for dma_addr_t
- Remove "file exists" check (now dead code since teardown removes file)
Note: The following fix was submitted separately via net:
- DMA in flight during teardown (call pci_clear_master before freeing
host memory):
https://lore.kernel.org/all/20260604213637.3844317-1-nikhil.rao@amd.com/
Changes since v1:
- Removed redefinition of __counted_by kernel primitive (Jakub Kicinski)
- Fixed kdoc warnings in pds_core_if.h
- Fixed checkpatch warnings
- Fixed bugs identified by sashiko:
Patch 2 (identity version 2):
- Zero data region before firmware commands
- Suppress expected error message during identify probe
Patch 3 (PLDM firmware update):
- Memory leak in pdsc_send_component_image() error path
- Memory leak in pdsc_flash_component() error path
- Missing devcmd_lock in pdsc_devcmd_finalize_update()
- Fixed dma_mapping_error() return value handling (returns boolean, not error code)
- Skip logic for components with index > 255
Patch 4 (component info):
- Added generic fw version display for all identity versions
- Handle components with both RUNNING and STARTUP flags
Patch 5 (host backed memory):
- Race between pdsc_remove and health thread (use-after-free)
- Set missing index field in MEM_QUERY command
- Host memory allocation size and zeroing
- Don't free host memory on MEM_ADD timeout (firmware may still be using it)
Patch 6 (debugfs):
- Fix dentry reference leak in debugfs_lookup (missing dput)
- Improvements:
- Cache component info to avoid repeated firmware queries (patch 4)
Note: The following fix for an existing bug was submitted separately
via net:
- Timeout error overwritten with stale status:
https://lore.kernel.org/netdev/20260515212907.998028-1-nikhil.rao@amd.com/
Link to v4: https://lore.kernel.org/netdev/20260614-upstream_v4-v4-0-f1c5765d90c2@amd.com/
Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
Brett Creeley (4):
pds_core: add support for quiet devcmd failures
pds_core: add support for identity version 2
pds_core: add PLDM firmware update support via devlink flash
pds_core: add PLDM component info display
Vamsi Atluri (2):
pds_core: add host backed memory support for firmware
pds_core: add debugfs support for host backed memory
.../device_drivers/ethernet/amd/pds_core.rst | 84 ++
drivers/net/ethernet/amd/Kconfig | 1 +
drivers/net/ethernet/amd/pds_core/core.c | 164 ++++
drivers/net/ethernet/amd/pds_core/core.h | 52 +-
drivers/net/ethernet/amd/pds_core/debugfs.c | 45 +
drivers/net/ethernet/amd/pds_core/dev.c | 136 ++-
drivers/net/ethernet/amd/pds_core/devlink.c | 137 ++-
drivers/net/ethernet/amd/pds_core/fw.c | 780 +++++++++++++++++-
drivers/net/ethernet/amd/pds_core/main.c | 11 +-
include/linux/pds/pds_core_if.h | 470 +++++++++++
10 files changed, 1857 insertions(+), 23 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v5 net-next 0/9] net: dsa: netc: add bridge mode support
From: patchwork-bot+netdevbpf @ 2026-06-15 21:50 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, andrew, olteanv, linux,
wei.fang, imx, netdev, linux-kernel, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20260611021458.2629145-1-wei.fang@oss.nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 11 Jun 2026 10:14:49 +0800 you wrote:
> From: Wei Fang <wei.fang@nxp.com>
>
> This series adds bridge mode support to the NETC DSA switch driver,
> covering both VLAN-aware and VLAN-unaware operation.
>
> The NETC switch manages forwarding through a set of hardware tables
> accessed via NTMP: the FDB table (FDBT), VLAN filter table (VFT), egress
> treatment table (ETT), and egress count table (ECT). The series extends
> the NTMP layer with the operations required for bridging, then builds the
> DSA bridge callbacks on top.
>
> [...]
Here is the summary with links:
- [v5,net-next,1/9] net: enetc: add interfaces to manage dynamic FDB entries
https://git.kernel.org/netdev/net-next/c/ca394837dfdd
- [v5,net-next,2/9] net: enetc: add "Update" and "Delete" operations to VLAN filter table
https://git.kernel.org/netdev/net-next/c/c52b6702a948
- [v5,net-next,3/9] net: enetc: add interfaces to manage egress treatment table
https://git.kernel.org/netdev/net-next/c/3cc291a35939
- [v5,net-next,4/9] net: enetc: add "Update" operation to the egress count table
https://git.kernel.org/netdev/net-next/c/d51f238a154a
- [v5,net-next,5/9] net: dsa: netc: initialize the group bitmap of ETT and ECT
https://git.kernel.org/netdev/net-next/c/1a58ae73dd74
- [v5,net-next,6/9] net: enetc: add helpers to set/clear table bitmap
https://git.kernel.org/netdev/net-next/c/8469b17310d1
- [v5,net-next,7/9] net: dsa: netc: add VLAN filter table and egress treatment management
https://git.kernel.org/netdev/net-next/c/84b4a3b30abd
- [v5,net-next,8/9] net: dsa: netc: add bridge mode support
https://git.kernel.org/netdev/net-next/c/751aa5a5d593
- [v5,net-next,9/9] net: dsa: netc: implement dynamic FDB entry ageing
https://git.kernel.org/netdev/net-next/c/05b5ee610fbb
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] octeontx2-pf: add page pool ethtool statistics
From: Jakub Kicinski @ 2026-06-15 21:50 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: linux-kernel, netdev, andrew+netdev, davem, edumazet, pabeni,
sgoutham
In-Reply-To: <20260615032141.521667-1-rkannoth@marvell.com>
On Mon, 15 Jun 2026 08:51:41 +0530 Ratheesh Kannoth wrote:
> Expose page pool allocator statistics through ethtool.
> When the interface is up, aggregate stats from each
> receive queue page pool and append the common page_pool ethtool stat
> block to the driver's private statistics set.
include/net/page_pool/helpers.h :
/* Deprecated driver-facing API, use netlink instead */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
int page_pool_ethtool_stats_get_count(void);
u8 *page_pool_ethtool_stats_get_strings(u8 *data);
u64 *page_pool_ethtool_stats_get(u64 *data, const void *stats);
Is the page pool in your driver shared by multiple netdevs?
If not just set netdev in page_pool_params
If yes then you need to explain it in the commit msg
Please note that net-next is closed for the next 2 weeks
--
pw-bot: cr
^ 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