* Re: [RFC PATCH 0/1] Proposal for in-band firmware update over PLDM-MCTP
From: Jeremy Kerr @ 2026-05-05 2:15 UTC (permalink / raw)
To: Badal Nilawar, dri-devel, intel-xe, netdev, linux-kernel
Cc: rodrigo.vivi, wojciech.drewek, michael.brooks, heikki.krogerus,
michael.j.ruhl, thomas.hellstrom, michal.winiarski,
anshuman.gupta, jacob.e.keller, maarten.lankhorst, matthew.brost,
anthony.l.nguyen, przemyslaw.kitszel, mika.westerberg,
andriy.shevchenko, singaravelan.nallasellan, kelvin.gardiner,
matt, andrew+netdev, davem, edumazet, kuba, pabeni, james.ausmus
In-Reply-To: <20260504193420.1232842-3-badal.nilawar@intel.com>
Hi Badal,
Thanks for sending this RFC through! It's good to have some early input
on the structure here.
> Problem statement:
This is exceptionally verbose for "we would like to add a MCTP transport
driver". :)
> Option 1: MCTP Transport as Part of drivers/gpu/drm/xe Subsystem
This sounds like the best approach to me. The MCTP transport drivers in
drivers/net/mctp are intended to be fairly hardware-agnostic, and all
are spec compliant. I see no issue with having your own code do a
mctp_register_netdev() from elsewhere in the tree.
I'll also reply on 1/1 with some implementation comments.
> Note: This RFC is prepared with AI assistance (e.g. GitHub Copilot etc).
Then please ensure you have read
Documentation/process/coding-assistants.rst, as you are missing the
Attribution requirements from that.
Cheers,
Jeremy
^ permalink raw reply
* Re: [RFC PATCH 1/1] xe/xe_mctp_mailbox: Add support for MCTP transport over mailbox
From: Jeremy Kerr @ 2026-05-05 2:15 UTC (permalink / raw)
To: Badal Nilawar, dri-devel, intel-xe, netdev, linux-kernel
Cc: rodrigo.vivi, wojciech.drewek, michael.brooks, heikki.krogerus,
michael.j.ruhl, thomas.hellstrom, michal.winiarski,
anshuman.gupta, jacob.e.keller, maarten.lankhorst, matthew.brost,
anthony.l.nguyen, przemyslaw.kitszel, mika.westerberg,
andriy.shevchenko, singaravelan.nallasellan, kelvin.gardiner,
matt, andrew+netdev, davem, edumazet, kuba, pabeni, james.ausmus
In-Reply-To: <20260504193420.1232842-4-badal.nilawar@intel.com>
Hi Badal,
> Add support for MCTP transport over the Intel vendor-specific mailbox
> protocol to enable in-band firmware updates for GPU/AMC via PLDM
I know this is an RFC, but you're missing the distinctive part, around
the hardware interactions on the transport side. The skeleton of a MCTP
driver is mostly the same as existing transport drivers, so there's not
a lot to comment on at present.
Some items on the parts here though:
I'd suggest not using the term "MCTP over mailbox" / mctp_mailbox in
general; there are lots of "mailbox" implementations around, including
the proposed PCC mailbox driver. Perhaps "MCTP over Xe mailbox"?
> diff --git a/drivers/gpu/drm/xe/xe_mctp_mailbox.c b/drivers/gpu/drm/xe/xe_mctp_mailbox.c
> new file mode 100644
> index 000000000000..f1a81208a9a1
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_mctp_mailbox.c
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: MIT
This will need to include GPLv2.
> +/*
> + * MCTP-over-MAILBOX transport for Xe.
> + *
> + * Copyright 2026 Intel Corporation
> + */
> +
> +#include "xe_device_types.h"
> +
> +#include <linux/netdevice.h>
> +#include <linux/jiffies.h>
> +#include <linux/workqueue.h>
> +
> +#include <net/mctp.h>
> +#include <net/mctpdevice.h>
> +#include <net/pkt_sched.h>
> +
> +#include <uapi/linux/if_arp.h>
> +
> +#include "xe_mctp_mailbox.h"
> +
> +#define XE_MCTP_MAILBOX_RX_POLL_MS 100
> +
> +/** @mctp_mailbox: Struct for mctp over mailbox */
> +struct xe_mctp_mailbox {
> + /** @mctp_mailbox.netdev: network device */
> + struct net_device *netdev;
> + /** @running: true while netdev is opened */
> + bool running;
> + /** @work: worker to handle mctp requests from firmware */
> + struct delayed_work work;
> + /** @wq: workqueue to schecdule mctp rx worker */
> + struct workqueue_struct *wq;
> +};
> +
> +/*
> + * mailbox protocol is interrupt free so for receive path i.e. endpoint to host
> + * there is no irq available so rx handler need to be polled in worker periodically.
> + */
This is unfortunate - there's no facility you can use to trigger RX?
> +static void mctp_mailbox_rx_handler(struct work_struct *work)
> +{
> + struct xe_mctp_mailbox *mctp_mailbox =
> + container_of(work, struct xe_mctp_mailbox, work.work);
> + struct net_device *netdev = mctp_mailbox->netdev;
> +
> + if (!netdev)
> + return;
> +
> + dev_hold(netdev);
> +
> + /*
> + * if (mctp_mailbox_rx_ready()) {
> + * Get data over MAILBOX
> + * Allocate skb and copy rx data to skb
> + * Queue skb to upper layer
> + * netif_rx(skb);
> + }
> + */
> + dev_put(netdev);
> +
> + if (mctp_mailbox->running)
> + queue_delayed_work(mctp_mailbox->wq, &mctp_mailbox->work,
> + msecs_to_jiffies(XE_MCTP_MAILBOX_RX_POLL_MS));
> +}
One packet per 100ms will mean you will very likely miss a retry timeout
on fragmented messages. You probably want to schedule the next RX
immediately until the mailbox is empty, assuming that will work with the
semantics of the Xe mailbox.
Even then, a single-packet (worst-case) transmission delay of 100ms is
getting a bit large. It may be necessary to increase the polling
frequency, but that has downsides. Hence the question about an RX
notification facility.
> +
> +static netdev_tx_t mctp_mailbox_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + /* RFC stub: send skb over MAILBOX */
> + dev_dstats_tx_dropped(dev);
> + kfree_skb(skb);
> +
> + return NETDEV_TX_OK;
> +}
> +
> +static int mctp_mailbox_open(struct net_device *dev)
> +{
> + struct xe_mctp_mailbox *mctp_mailbox = netdev_priv(dev);
> +
> + mctp_mailbox->running = true;
> + netif_start_queue(dev);
> +
> + queue_delayed_work(mctp_mailbox->wq, &mctp_mailbox->work, 0);
> +
> + return 0;
> +}
> +
> +static int mctp_mailbox_stop(struct net_device *dev)
> +{
> + struct xe_mctp_mailbox *mctp_mailbox = netdev_priv(dev);
> +
> + mctp_mailbox->running = false;
> + netif_stop_queue(dev);
> +
> + cancel_delayed_work_sync(&mctp_mailbox->work);
> + flush_workqueue(mctp_mailbox->wq);
> +
> + return 0;
> +}
> +
> +static const struct net_device_ops mctp_mailbox_netdev_ops = {
> + .ndo_start_xmit = mctp_mailbox_start_xmit,
> + .ndo_open = mctp_mailbox_open,
> + .ndo_stop = mctp_mailbox_stop,
> +};
> +
> +static void mctp_mailbox_netdev_setup(struct net_device *dev)
> +{
> + /* Populate netdev structure */
> + dev->type = ARPHRD_MCTP;
> + /*
> + * dev->mtu = MCTP_MAILBOX_MTU_MIN;
> + * dev->min_mtu = MCTP_MAILBOX_MTU_MIN;
> + * dev->max_mtu = MCTP_MAILBOX_MTU_MAX;
> + *
> + * dev->hard_header_len = sizeof(struct mctp_mailbox_hdr);
What's in struct mctp_mailbox_hdr? I assume you don't need to handle any
physical addressing, but can you confirm?
> + * dev->tx_queue_len = DEFAULT_TX_QUEUE_LEN;
> + */
> + dev->flags = IFF_NOARP;
> + dev->netdev_ops = &mctp_mailbox_netdev_ops;
> + dev->pcpu_stat_type = NETDEV_PCPU_STAT_DSTATS;
> +}
> +
> +static void xe_mctp_mailbox_fini(void *arg)
> +{
> + struct xe_device *xe = arg;
> + struct xe_mctp_mailbox *mctp_mailbox = xe->mctp_mailbox;
> + struct net_device *netdev;
> +
> + if (!mctp_mailbox)
> + return;
> +
> + netdev = mctp_mailbox->netdev;
> + if (!netdev) {
> + xe->mctp_mailbox = NULL;
> + return;
> + }
> +
> + if (mctp_mailbox->wq) {
> + mctp_mailbox->running = false;
> + cancel_delayed_work_sync(&mctp_mailbox->work);
> + destroy_workqueue(mctp_mailbox->wq);
> + mctp_mailbox->wq = NULL;
> + }
> +
> + xe->mctp_mailbox = NULL;
> + mctp_unregister_netdev(netdev);
> + free_netdev(netdev);
> +}
> +
> +int xe_mctp_mailbox_init(struct xe_device *xe)
> +{
> + struct xe_mctp_mailbox *mctp_mailbox;
> + struct net_device *netdev;
> + int ret, err;
> +
> + netdev = alloc_netdev(sizeof(*mctp_mailbox), "mctp_mailbox%d", NET_NAME_ENUM,
> + mctp_mailbox_netdev_setup);
I'd suggest mctpxe%d here. We don't tend to have underscores in netdev
names, and 'mailbox' is quite generic.
Can you tie the name to the instance of the GPU (and then use
NET_NAME_PREDICTABLE) perhaps?
> + if (!netdev)
> + return -ENOMEM;
> +
> + SET_NETDEV_DEV(netdev, xe->drm.dev);
> + mctp_mailbox = netdev_priv(netdev);
> + mctp_mailbox->netdev = netdev;
> +
> + ret = mctp_register_netdev(netdev, NULL, MCTP_PHYS_BINDING_VENDOR);
> + if (ret) {
> + free_netdev(netdev);
> + return ret;
> + }
> +
> + INIT_DELAYED_WORK(&mctp_mailbox->work, mctp_mailbox_rx_handler);
> + mctp_mailbox->wq = alloc_ordered_workqueue("mctp-mailbox-ordered-wq", 0);
> + if (!mctp_mailbox->wq) {
> + mctp_unregister_netdev(netdev);
> + free_netdev(netdev);
> + return -ENOMEM;
> + }
> +
> + xe->mctp_mailbox = mctp_mailbox;
> + err = devm_add_action_or_reset(xe->drm.dev, xe_mctp_mailbox_fini, xe);
> + if (err)
> + return err;
> +
> + return 0;
> +}
Cheers,
Jeremy
^ permalink raw reply
* Re: [PATCH net-next V2 7/7] net/mlx5: Add profile to auto-enable switchdev mode at device init
From: Jakub Kicinski @ 2026-05-05 2:19 UTC (permalink / raw)
To: Mark Bloch
Cc: Tariq Toukan, Eric Dumazet, Paolo Abeni, Andrew Lunn,
David S. Miller, Leon Romanovsky, Jason Gunthorpe, Saeed Mahameed,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Gerd Bayer, Moshe Shemesh, Kees Cook,
Patrisious Haddad, Parav Pandit, Carolina Jubran, Cosmin Ratiu,
linux-rdma, linux-kernel, netdev, Gal Pressman, Dragos Tatulea
In-Reply-To: <9f73036e-32a8-4060-a347-cae05269b85f@nvidia.com>
On Tue, 5 May 2026 05:00:15 +0300 Mark Bloch wrote:
> What I meant is that I am wary of putting too much policy into the kernel
> command line. A generic devlink level switchdev probe mode knob sounds
> reasonable to me if we keep the scope narrow. More complex policy, such as
> changing multiple defaults still seems better handled by userspace.
>
> Would adding only switchdev/switchdev_inactive for now be acceptable?
> I will try to keep the code generic enough so it can be extended later if
> we want.
I wanted the format to be reasonably generic, but yes, just for making
future extensions possible. I don't expect us to add anything beyond
the switchdev flag at this point. We don't have to implement the device
matching either. Just a comment in the code how we expect the full
format to look like would be enough, for whoever needs it in the future.
^ permalink raw reply
* Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
From: patchwork-bot+netdevbpf @ 2026-05-05 2:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet, AVKrasnov,
stefanha, sgarzare, mst, jasowang, xuanzhuo, eperezma, kvm,
virtualization
In-Reply-To: <20260430122653.554058-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 30 Apr 2026 12:26:52 +0000 you wrote:
> virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>
> virtio_transport_recv_enqueue() skips coalescing for packets
> with VIRTIO_VSOCK_SEQ_EOM.
>
> If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> a very large number of packets can be queued
> because vvs->rx_bytes stays at 0.
>
> [...]
Here is the summary with links:
- [net] vsock/virtio: fix potential unbounded skb queue
https://git.kernel.org/netdev/net/c/059b7dbd20a6
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] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
From: patchwork-bot+netdevbpf @ 2026-05-05 2:20 UTC (permalink / raw)
To: Markus Baier
Cc: o.rempel, andrew+netdev, davem, edumazet, kuba, pabeni, linux,
enelsonmoore, linmq006, linux-usb, netdev, linux-kernel
In-Reply-To: <20260501163941.107668-1-Markus.Baier@soslab.tu-darmstadt.de>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 1 May 2026 18:39:41 +0200 you wrote:
> Commit e0bffe3e6894 ("net: asix: ax88772: migrate to phylink") replaced
> the asix_adjust_link() PHY callback with phylink's mac_link_up() and
> mac_link_down() handlers, but did not carry over the usbnet_link_change()
> notification that commit 805206e66fab ("net: asix: fix "can't send until
> first packet is send" issue") had added.
>
> As a result, the original symptom returns: when the link comes up,
> usbnet is never notified, so the RX URB submission stays dormant until
> some other event (e.g. a transmitted packet triggering the status
> endpoint interrupt) wakes it up.
>
> [...]
Here is the summary with links:
- [net] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
https://git.kernel.org/netdev/net/c/36bdc0e815b4
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 v6 0/5] net: bridge: mcast: support exponential field encoding
From: patchwork-bot+netdevbpf @ 2026-05-05 2:20 UTC (permalink / raw)
To: Ujjal Roy
Cc: davem, edumazet, kuba, pabeni, horms, razor, idosch, dsahern,
shuah, aroulin, yongwang, petrm, ujjal, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260502131907.987-1-royujjal@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 13:19:01 +0000 you wrote:
> Description:
> This series addresses a mismatch in how multicast query
> intervals and response codes are handled across IPv4 (IGMPv3)
> and IPv6 (MLDv2). While decoding logic currently exists,
> the corresponding encoding logic is missing during query
> packet generation. This leads to incorrect intervals being
> transmitted when values exceed their linear thresholds.
>
> [...]
Here is the summary with links:
- [net-next,v6,1/5] ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation
https://git.kernel.org/netdev/net-next/c/726fa7da2d8c
- [net-next,v6,2/5] ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()
https://git.kernel.org/netdev/net-next/c/12cfb4ecc471
- [net-next,v6,3/5] ipv4: igmp: encode multicast exponential fields
https://git.kernel.org/netdev/net-next/c/95bfd196f0dc
- [net-next,v6,4/5] ipv6: mld: encode multicast exponential fields
https://git.kernel.org/netdev/net-next/c/e51560f4220a
- [net-next,v6,5/5] selftests: net: bridge: add MRC and QQIC field encoding tests
https://git.kernel.org/netdev/net-next/c/529dbe762de0
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 0/3] net: Convert AF_NETLINK and AF_VSOCK to getsockopt_iter API
From: patchwork-bot+netdevbpf @ 2026-05-05 2:20 UTC (permalink / raw)
To: Breno Leitao
Cc: davem, edumazet, kuba, pabeni, horms, sgarzare, shuah, sdf.kernel,
netdev, linux-kernel, virtualization, linux-kselftest,
kernel-team
In-Reply-To: <20260501-getsock_one-v1-0-810ce23ea70e@debian.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 01 May 2026 08:52:50 -0700 you wrote:
> Continue the work to convert protocols to the new getsockopt_iter API.
>
> Convert AF_NETLINK and AF_VSOCK getsockopt implementations to the new
> sockopt_t/getsockopt_iter API, and add kselftests that verify the size
> and errno semantics are preserved across the conversion.
>
> I chose these two socket families because they are probably one of the
> most used protocols,, ensuring that any potential bugs will be
> discovered and reported quickly.
>
> [...]
Here is the summary with links:
- [net-next,1/3] netlink: convert to getsockopt_iter
https://git.kernel.org/netdev/net-next/c/390bf43b7788
- [net-next,2/3] vsock: convert to getsockopt_iter
https://git.kernel.org/netdev/net-next/c/e21bf72954df
- [net-next,3/3] net: selftests: add getsockopt_iter regression tests
https://git.kernel.org/netdev/net-next/c/d39887f55d8e
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] net/sched: add qstats_cpu_drop_inc() helper
From: patchwork-bot+netdevbpf @ 2026-05-05 2:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260501135916.2566766-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 1 May 2026 13:59:16 +0000 you wrote:
> 1) Using this_cpu_inc() is better than going through this_cpu_ptr():
>
> - Single instruction on x86.
> - Store tearing prevention.
>
> 2) Change tcf_action_update_stats() to use this_cpu_add().
>
> [...]
Here is the summary with links:
- [net-next] net/sched: add qstats_cpu_drop_inc() helper
https://git.kernel.org/netdev/net-next/c/3f3aa77ff1c8
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 v3 2/3] r8152: Add support for the RTL8159 chip
From: Jakub Kicinski @ 2026-05-05 2:30 UTC (permalink / raw)
To: mail
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, linux-usb,
netdev, linux-kernel, hsu.chih.kai, olek2
In-Reply-To: <20260502-rtl8159_net_next-v3-2-12c895d46cd6@birger-koblitz.de>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
r8152: Add support for the RTL8159 chip
This patch adds support for the RTL8159 chip as RTL_VER_17, reusing the
RTL8157 initialization and USB power management paths. The bulk of the
new code lives in r8157_hw_phy_cfg() to configure the RTL8159 PHY, and
the USB product ID 0x815a is added to the device table.
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 05abfab1df94..a2cdd57558c7 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
[ ... ]
> @@ -7996,7 +8005,7 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
> /* Advanced Power Saving parameter */
> ocp_reg_set_bits(tp, 0xa430, BIT(0) | BIT(1));
>
> - /* aldpsce force mode */
> + /* Disable ALDPS force mode */
> ocp_reg_clr_bits(tp, 0xa44a, BIT(2));
>
> switch (tp->version) {
> @@ -8120,6 +8129,190 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
> sram2_write_w0w1(tp, 0x807c, 0xff00, 0x5000);
> sram2_write_w0w1(tp, 0x809d, 0xff00, 0x5000);
> break;
> +
> + case RTL_VER_17:
> + /* Disable bypass turn off clk in ALDPS */
> + ocp_byte_clr_bits(tp, MCU_TYPE_PLA, 0xd3c8, BIT(0));
^
Is the leading space before ocp_byte_clr_bits here intentional? The rest
of the switch statement uses a single tab for indentation. checkpatch.pl
should catch this.
> +
> + /* Power level tuning
> + * test mode power level
> + */
> + sram_write_w0w1(tp, 0x8415, 0xff00, 0x9300);
> + /* normal link power level 10G, 5G, 2.5G */
> + sram_write_w0w1(tp, 0x81a3, 0xff00, 0x0f00);
> + sram_write_w0w1(tp, 0x81ae, 0xff00, 0x0f00);
> + sram_write_w0w1(tp, 0x81b9, 0xff00, 0xb900);
> + /* nomal link TX filter */
^^^^^
Small typo, "nomal" -> "normal".
> + sram2_write_w0w1(tp, 0x83b0, 0x0e00, 0);
> + sram2_write_w0w1(tp, 0x83c5, 0x0e00, 0);
> + sram2_write_w0w1(tp, 0x83da, 0x0e00, 0);
> + sram2_write_w0w1(tp, 0x83ef, 0x0e00, 0);
[ ... ]
> + /* Slave about EC mu of datamode AAGC and DAC BG */
> + sram2_write_w0w1(tp, 0x88ac, 0xff00, 0x2300);
> + /* improve UBE */
> + ocp_reg_set_bits(tp, 0xbf0c, 0x7 << 11);
> + /* close Sparse NEC, improve connect 5EUU calble performace */
^^^^^ ^^^^^^^^^
Two typos here, "calble" -> "cable" and "performace" -> "performance".
> + sram2_write_w0w1(tp, 0x88de, 0xff00, 0);
> + /* 5G slave compatibility issue (will include in v10) */
^^^^^^^^^^^^^^^^^^
Is this "will include in v10" comment a reference to an internal Realtek
source-tree revision? It does not appear to have meaning in the upstream
tree and could be dropped or rephrased.
> + sram2_write(tp, 0x80b4, 0x5195);
[ ... ]
> + sram2_write_w0w1(tp, 0x88d5, 0xff00, 0x0200);
> + break;
> +
> default:
> break;
> }
[ ... ]
> @@ -8155,6 +8348,18 @@ static void r8157_hw_phy_cfg(struct r8152 *tp)
> set_bit(PHY_RESET, &tp->flags);
> }
>
> +static int r8159_wait_backup_restore(struct r8152 *tp)
> +{
> + u32 ocp_data;
> +
> + ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
> + if (!(ocp_data & PCUT_STATUS))
> + return 0;
> +
> + return poll_timeout_us(ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_GPHY_CTRL),
> + ocp_data & BACKUP_RESTRORE, 200, 20000, false);
> +}
> +
> static void r8156_init(struct r8152 *tp)
> {
> u32 ocp_data;
[ ... ]
> @@ -8201,6 +8407,11 @@ static void r8156_init(struct r8152 *tp)
> return;
> }
>
> + if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp)) {
> + dev_err(&tp->intf->dev, "init failed, backup-restore timed out\n");
> + return;
> + }
> +
On timeout this returns early from r8156_init() and skips the remainder of
the init sequence, including r8157_u2p3en()/r8157_power_cut_en(),
r8156_ups_en(), r8153_queue_wake(), rtl_runtime_suspend_enable(),
r8156_mac_clk_spd(), the rx aggregation / 16-byte Rx descriptor
configuration, r8156_mdio_force_mode(), rtl_tally_reset() and the
tp->coalesce assignment.
r8156_init() is void and rtl8152_probe_once() does not check init status,
so probe continues and register_netdev() runs after this early return.
Should this path also set RTL8152_INACCESSIBLE on tp->flags, or should the
init callback be changed to return an error that probe can honor, so that
a half-initialized device is not exposed to userspace?
> data = r8153_phy_status(tp, 0);
> if (data == PHY_STAT_EXT_INIT) {
> ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
[ ... ]
> @@ -8274,7 +8485,10 @@ static void r8156_init(struct r8152 *tp)
> set_bit(GREEN_ETHERNET, &tp->flags);
>
> /* rx aggregation / 16 bytes Rx descriptor */
> - if (tp->version == RTL_VER_16)
> + if (tp->version == RTL_VER_17)
> + ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
> + RX_AGG_DISABLE | RX_DESC_16B | BIT(11));
^^^^^^
What does BIT(11) in USB_USB_CTRL correspond to here, and is it
RTL8159-specific?
The commit message says the RTL8159 "reuses hardware features of the
RTL8157 (RTL_VER_16)", but this path clears an extra bit that the
RTL_VER_16 path does not. Since there is no symbolic name or comment,
it is hard to tell whether RTL_VER_16 is missing this clear, whether
RTL_VER_17 should not be clearing it, or whether it really is an
RTL8159-only quirk.
Could a named define and/or a short comment be added to describe what
this bit does?
> + else if (tp->version == RTL_VER_16)
> ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_DESC_16B);
> else
> ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_ZERO_EN);
[ ... ]
^ permalink raw reply
* Re: [PATCH net 0/4] mptcp: misc fixes for v7.1-rc3
From: patchwork-bot+netdevbpf @ 2026-05-05 2:30 UTC (permalink / raw)
To: Matthieu Baerts
Cc: martineau, geliang, davem, edumazet, kuba, pabeni, horms, fw,
yangang, dmytro, netdev, mptcp, linux-kernel, shardul.b, stable
In-Reply-To: <20260501-net-mptcp-misc-fixes-7-1-rc3-v1-0-b70118df778e@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 01 May 2026 21:35:33 +0200 you wrote:
> Here are various unrelated fixes:
>
> - Patch 1: increment the right MIB counter. A fix for v5.7.
>
> - Patch 2: set the right MPTCP reset reason. A fix for v5.9.
>
> - Patch 3: fix rx timestamp corruption when on MPTCP passive fastopen. A
> fix for v6.2.
>
> [...]
Here is the summary with links:
- [net,1/4] mptcp: use MPJoinSynAckHMacFailure for SynAck HMAC failure
https://git.kernel.org/netdev/net/c/c4a99a921949
- [net,2/4] mptcp: use MPTCP_RST_EMPTCP for ACK HMAC validation failure
https://git.kernel.org/netdev/net/c/a6da02d4c00f
- [net,3/4] mptcp: fix rx timestamp corruption on fastopen
https://git.kernel.org/netdev/net/c/6254a16d6f0c
- [net,4/4] mptcp: sockopt: increase seq in mptcp_setsockopt_all_sf
https://git.kernel.org/netdev/net/c/70ece9d7021c
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 v2] net: mana: hardening: Reject zero max_num_queues from MANA_QUERY_VPORT_CONFIG
From: patchwork-bot+netdevbpf @ 2026-05-05 2:30 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, dipayanroy, shirazsaleem, kees,
linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260430085638.1875400-1-ernis@linux.microsoft.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 30 Apr 2026 01:56:31 -0700 you wrote:
> As a part of MANA hardening for CVM, validate that max_num_sq and
> max_num_rq returned by MANA_QUERY_VPORT_CONFIG are not zero. These
> values flow into apc->num_queues, which is used as an allocation count
> and loop bound. A zero value would result in zero-size allocations and
> incorrect driver behavior.
>
> Return -EPROTO if either value is zero.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: mana: hardening: Reject zero max_num_queues from MANA_QUERY_VPORT_CONFIG
https://git.kernel.org/netdev/net-next/c/93ca1575dd1f
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 v2] net: mana: hardening: Reject zero max_num_queues from GDMA_QUERY_MAX_RESOURCES
From: patchwork-bot+netdevbpf @ 2026-05-05 2:30 UTC (permalink / raw)
To: Erni Sri Satya Vennela
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, shradhagupta, dipayanroy,
yury.norov, linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260430083627.1873757-1-ernis@linux.microsoft.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 30 Apr 2026 01:36:21 -0700 you wrote:
> In a CVM environment, hardware responses cannot be trusted. The
> GDMA_QUERY_MAX_RESOURCES command returns resource limits used to
> determine the maximum number of queues.
>
> In mana_gd_query_max_resources(), gc->max_num_queues is initialized
> from num_online_cpus() and successively clamped by the hardware-reported
> max_eq, max_cq, max_sq, max_rq, and num_msix_usable values. If any of
> these hardware values is zero, gc->max_num_queues becomes zero and the
> function returns success. This leads to a confusing failure later when
> alloc_etherdev_mq() is called with zero queues, returning NULL and
> producing a misleading -ENOMEM error.
>
> [...]
Here is the summary with links:
- [net-next,v2] net: mana: hardening: Reject zero max_num_queues from GDMA_QUERY_MAX_RESOURCES
https://git.kernel.org/netdev/net-next/c/f7622e58e802
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] net: phy: realtek: replace magic number with register bit macros
From: patchwork-bot+netdevbpf @ 2026-05-05 2:30 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, daniel,
vladimir.oltean, michael, ih, rmk+kernel, marek.vasut, netdev,
linux-kernel
In-Reply-To: <20260502092857.156831-1-olek2@wp.pl>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 11:28:47 +0200 you wrote:
> Replace magic number with register bit macros. The description of the
> RTL8211B interrupt register is obtained from publicly available
> datasheet[1].
>
> 1. RTL8211B(L) Rev. 1.5 Datasheet
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
>
> [...]
Here is the summary with links:
- [net-next] net: phy: realtek: replace magic number with register bit macros
https://git.kernel.org/netdev/net-next/c/052065add1b5
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 v3] psp: strip variable-length PSP header in psp_dev_rcv()
From: patchwork-bot+netdevbpf @ 2026-05-05 2:40 UTC (permalink / raw)
To: David CARLIER
Cc: daniel.zahka, kuba, willemdebruijn.kernel, davem, edumazet,
pabeni, horms, raeds, kees, cratiu, netdev, linux-kernel, willemb,
stable
In-Reply-To: <20260502141945.14484-1-devnexen@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 15:19:45 +0100 you wrote:
> psp_dev_rcv() unconditionally removes a fixed PSP_ENCAP_HLEN, even
> when psph->hdrlen indicates that the PSP header carries optional
> fields. A frame whose PSP header advertises a non-zero VC or any
> extension would therefore be silently mis-decapsulated: option bytes
> would spill into the inner packet head and downstream parsing would
> fail on a corrupted skb.
>
> [...]
Here is the summary with links:
- [net,v3] psp: strip variable-length PSP header in psp_dev_rcv()
https://git.kernel.org/netdev/net/c/30cb24f97d44
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 v6] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: patchwork-bot+netdevbpf @ 2026-05-05 2:40 UTC (permalink / raw)
To: Daniel Golle
Cc: chester.a.unal, andrew, olteanv, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, ansuelsmth,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <6940b913da2c29156f0feff74b678d3c526ee84c.1777719253.git.daniel@makrotopia.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 11:55:02 +0100 you wrote:
> The .get_stats64 callback runs in atomic context, but on
> MDIO-connected switches every register read acquires the MDIO bus
> mutex, which can sleep:
> [ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
> [ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
> [ 12.663377] preempt_count: 0, expected: 0
> [ 12.667410] RCU nest depth: 1, expected: 0
> [ 12.671511] INFO: lockdep is turned off.
> [ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
> [ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> [ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
> [ 12.675459] Call trace:
> [ 12.675462] show_stack+0x14/0x1c (C)
> [ 12.675477] dump_stack_lvl+0x68/0x8c
> [ 12.675487] dump_stack+0x14/0x1c
> [ 12.675495] __might_resched+0x14c/0x220
> [ 12.675504] __might_sleep+0x44/0x80
> [ 12.675511] __mutex_lock+0x50/0xb10
> [ 12.675523] mutex_lock_nested+0x20/0x30
> [ 12.675532] mt7530_get_stats64+0x40/0x2ac
> [ 12.675542] dsa_user_get_stats64+0x2c/0x40
> [ 12.675553] dev_get_stats+0x44/0x1e0
> [ 12.675564] dev_seq_printf_stats+0x24/0xe0
> [ 12.675575] dev_seq_show+0x14/0x3c
> [ 12.675583] seq_read_iter+0x37c/0x480
> [ 12.675595] seq_read+0xd0/0xec
> [ 12.675605] proc_reg_read+0x94/0xe4
> [ 12.675615] vfs_read+0x98/0x29c
> [ 12.675625] ksys_read+0x54/0xdc
> [ 12.675633] __arm64_sys_read+0x18/0x20
> [ 12.675642] invoke_syscall.constprop.0+0x54/0xec
> [ 12.675653] do_el0_svc+0x3c/0xb4
> [ 12.675662] el0_svc+0x38/0x200
> [ 12.675670] el0t_64_sync_handler+0x98/0xdc
> [ 12.675679] el0t_64_sync+0x158/0x15c
>
> [...]
Here is the summary with links:
- [net,v6] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
https://git.kernel.org/netdev/net/c/07d995873960
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 v1 net] ipmr: Add __rcu to netns_ipv4.mrt.
From: patchwork-bot+netdevbpf @ 2026-05-05 2:40 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, horms, kuni1840, netdev, lkp
In-Reply-To: <20260502180755.359554-1-kuniyu@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 18:07:47 +0000 you wrote:
> kernel test robot reported this Sparse warning:
>
> $ make C=1 net/ipv4/ipmr.o
> net/ipv4/ipmr.c:312:24: error: incompatible types in comparison expression (different address spaces):
> net/ipv4/ipmr.c:312:24: struct mr_table [noderef] __rcu *
> net/ipv4/ipmr.c:312:24: struct mr_table *
>
> [...]
Here is the summary with links:
- [v1,net] ipmr: Add __rcu to netns_ipv4.mrt.
https://git.kernel.org/netdev/net/c/a6039776c799
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] net: prevent possible UAF in rtnl_prop_list_size()
From: patchwork-bot+netdevbpf @ 2026-05-05 2:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet
In-Reply-To: <20260502124102.499204-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 12:41:02 +0000 you wrote:
> I was mistaken by synchronize_rcu() [1] call in netdev_name_node_alt_destroy(),
> giving a false sense of RCU safety at delete times.
>
> We have to use list_del_rcu() to not confuse potential readers
> in rtnl_prop_list_size().
>
> [1] This synchronize_rcu() call was later removed in commit 723de3ebef03
> ("net: free altname using an RCU callback").
>
> [...]
Here is the summary with links:
- [net] net: prevent possible UAF in rtnl_prop_list_size()
https://git.kernel.org/netdev/net/c/ac0841d7d202
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] net/sched: speedup tc_dump_qdisc() when tcm_handle is provided
From: patchwork-bot+netdevbpf @ 2026-05-05 2:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260503114515.2460477-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 3 May 2026 11:45:15 +0000 you wrote:
> "tc qdisc show ... handle xxx" filtering can be done by the kernel.
>
> A followup patch can do the same for tcm_parent.
>
> iproute2/tc needs a small companion patch.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> [...]
Here is the summary with links:
- [net-next] net/sched: speedup tc_dump_qdisc() when tcm_handle is provided
https://git.kernel.org/netdev/net-next/c/c1e5127b577c
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 v3] net: airoha: Introduce airoha_fe_get()/airoha_qdma_get() register read helpers
From: patchwork-bot+netdevbpf @ 2026-05-05 2:40 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260501-airoha_fe_get-airoha_qdma_get-v3-1-126c6f647ccb@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 01 May 2026 09:49:11 +0200 you wrote:
> Add airoha_fe_get() and airoha_qdma_get() as utility routines for reading
> a masked field from a specified register.
> This is a non-functional refactor, no logical changes are introduced to
> the existing codebase.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net-next,v3] net: airoha: Introduce airoha_fe_get()/airoha_qdma_get() register read helpers
https://git.kernel.org/netdev/net-next/c/98e490930de3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2] net: stmmac: Add support for TX/RX channel interrupt
From: muhammad.nazim.amirul.nazle.asmade @ 2026-05-05 2:44 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, pabeni, edumazet, andrew+netdev, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Enable TX/RX channel interrupt registration for MAC that interrupts CPU
through shared peripheral interrupt (SPI).
Per-channel interrupts and interrupt-names are registered as follows,
e.g. 4 TX and 4 RX channels:
interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "dma_tx0",
"dma_tx1",
"dma_tx2",
"dma_tx3",
"dma_rx0",
"dma_rx1",
"dma_rx2",
"dma_rx3";
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v2:
- Use -ENXIO to detect when interrupt name is not present,
and return any other negative error code to the caller.
---
.../ethernet/stmicro/stmmac/stmmac_platform.c | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5cae2aa72906..9039e207ddbd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -732,6 +732,9 @@ static int stmmac_pltfr_get_irq_array(struct platform_device *pdev,
int stmmac_get_platform_resources(struct platform_device *pdev,
struct stmmac_resources *stmmac_res)
{
+ char irq_name[9];
+ int i;
+ int irq;
int ret;
memset(stmmac_res, 0, sizeof(*stmmac_res));
@@ -767,6 +770,30 @@ int stmmac_get_platform_resources(struct platform_device *pdev,
dev_info(&pdev->dev, "IRQ sfty not found\n");
}
+ /* For RX Channel */
+ for (i = 0; i < MTL_MAX_RX_QUEUES; i++) {
+ snprintf(irq_name, sizeof(irq_name), "dma_rx%i", i);
+ irq = platform_get_irq_byname_optional(pdev, irq_name);
+ if (irq == -ENXIO)
+ break;
+ else if (irq < 0)
+ return irq;
+
+ stmmac_res->rx_irq[i] = irq;
+ }
+
+ /* For TX Channel */
+ for (i = 0; i < MTL_MAX_TX_QUEUES; i++) {
+ snprintf(irq_name, sizeof(irq_name), "dma_tx%i", i);
+ irq = platform_get_irq_byname_optional(pdev, irq_name);
+ if (irq == -ENXIO)
+ break;
+ else if (irq < 0)
+ return irq;
+
+ stmmac_res->tx_irq[i] = irq;
+ }
+
stmmac_res->addr = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(stmmac_res->addr))
--
2.43.7
^ permalink raw reply related
* Re: [PATCH net v2] xfrm: esp: avoid in-place decrypt on shared skb frags
From: Hex Rabbit @ 2026-05-05 2:49 UTC (permalink / raw)
To: Hyunwoo Kim
Cc: Steffen Klassert, netdev, Greg Kroah-Hartman, Herbert Xu,
Simon Horman, David S . Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Ido Schimmel, linux-kernel
In-Reply-To: <afjrqlBPSv0X9kaY@v4bel>
Hi Hyunwoo, Steffen,
> The report and patch for this issue were already posted on
> the public netdev ML 6 days ago, i.e., the bug was already
> publicly reported:
>
> https://lore.kernel.org/all/afLDKSvAvMwGh7Fy@v4bel/
>
> Credit for patch authorship is adequately covered by
> Signed-off-by alone. Setting aside that your work proceeded
> independently rather than as a review of my earlier
> submission, the trailer should conform to convention to
> avoid future misunderstanding.
For clarity, I also found and reported the issue independently to
security@kernel.org on the same day, with my own reproducer and
root-cause analysis. At that time I was not aware of your report or
patch; otherwise I would have referenced it earlier.
I am still not fully familiar with the exact kernel trailer convention
here, so I added both Reported-by tags because the reports were
independent.
Steffen, either trailer form is fine with me. If you decide to drop my
Reported-by because the patch already has my Signed-off-by, I have no
objection.
Thanks,
Kuan-Ting
^ permalink raw reply
* Re: [PATCH] net: stmmac: Add support for TX/RX channel interrupt
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-05-05 2:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com, andrew+netdev@lunn.ch,
linux-kernel@vger.kernel.org
In-Reply-To: <42b173da-5c0b-4d72-9247-49ebec5e95e5@lunn.ch>
On 1/5/2026 4:53 am, Andrew Lunn wrote:
> [You don't often get email from andrew@lunn.ch. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
>> + /* For RX Channel */
>> + for (i = 0; i < MTL_MAX_RX_QUEUES; i++) {
>> + snprintf(irq_name, sizeof(irq_name), "dma_rx%i", i);
>> + irq = platform_get_irq_byname_optional(pdev, irq_name);
>> + if (irq == -EPROBE_DEFER)
>> + return irq;
>> + else if (irq < 0)
>> + break;
>
> It would be good to differentiate between real errors, and it not
> being available. I think -ENOXIO is returned when it does not
> exist. Anything else is a real error?
>
> Andrew
comment have been addressed and updated in v2
https://lore.kernel.org/all/20260505024459.22463-1-muhammad.nazim.amirul.nazle.asmade@altera.com/
Nazim
^ permalink raw reply
* [PATCH ipsec-next v8 00/14] xfrm: XFRM_MSG_MIGRATE_STATE new netlink message
From: Antony Antony @ 2026-05-05 4:31 UTC (permalink / raw)
To: Antony Antony, Steffen Klassert, Herbert Xu, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Masahide NAKAMURA, Paul Moore, Stephen Smalley,
Ondrej Mosnacek, Jonathan Corbet, Shuah Khan
Cc: Sabrina Dubroca, netdev, linux-kernel, selinux, linux-doc,
Chiachang Wang, Yan Yan, devel
The current XFRM_MSG_MIGRATE interface is tightly coupled to policy and
SA migration, and it lacks the information required to reliably migrate
individual SAs. This makes it unsuitable for IKEv2 deployments,
dual-stack setups (IPv4/IPv6), and scenarios where policies are managed
externally (e.g., by daemons other than the IKE daemon).
Mandatory SA selector list
The current API requires a non-empty SA selector list, which does not
reflect the IKEv2 use case.
A single Child SA may correspond to multiple policies,
and SA discovery already occurs via address and reqid matching. With
dual-stack Child SAs this leads to excessive churn: the current method
would have to be called up to six times (in/out/fwd × v4/v6) on SA,
while the new method only requires two calls.
Selectors lack SPI (and marks)
XFRM_MSG_MIGRATE cannot uniquely identify an SA when multiple SAs share
the same policies (per-CPU SAs, SELinux label-based SAs, etc.). Without
the SPI, the kernel may update the wrong SA instance.
Reqid cannot be changed
Some implementations allocate reqids based on traffic selectors. In
host-to-host or selector-changing scenarios, the reqid must change,
which the current API cannot express.
Because strongSwan and other implementations manage policies
independently of the kernel, an interface that updates only a specific
SA - with complete and unambiguous identification - is required.
SA Selector, x->sel, can't be changed, especially Transport mode.
XFRM_MSG_MIGRATE_STATE provides that interface. It supports migration
of a single SA via xfrm_usersa_id (including SPI) and we fix
encap removal in this patch set, reqid updates, address changes,
and other SA-specific parameters. It avoids the structural limitations
of XFRM_MSG_MIGRATE and provides a simpler, extensible mechanism for
precise per-SA migration without involving policies.
This method also allows migtrating SA selectors typically used with
host-to-host in Transport mode.
New migration steps: first install block policy, remove the old policy,
call XFRM_MSG_MIGRATE_STATE for each state, then re-install the
policies and remove the block policy.
If the target SA tuple (daddr, SPI, proto, family) is already
occupied, the operation returns -EEXIST. In this case the original
SA is not preserved. Userspace must handle -EEXIST by
re-establishing the SA at the IKE level and manage policies.
---
v7->v8: - removed the unknown-flags validation block
Link to v7: https://patch.msgid.link/migrate-state-v7-14-44eb2440b91c@secunet.com
v6->v7: - add SA selectoor migration
- fixes to commit messages
- white space removal
Link to v6: https://lore.kernel.org/r/migrate-state-v6-0-9df9764ddb9e@secunet.com
v5->v6: - add mark to look up SA.
- restrict netlink attributes in new method
- address review feedback from Sabrina
- add new patch to fix existing inter-family address comparison
- add extack xfrm_state_init()
- Feedback from Yan : omit-to-inherit add migrating marks
- Drop missing __rcu annotation on nlsk, Sabrina has a better patch
Link to v5: https://lore.kernel.org/all/cover.1769509130.git.antony.antony@secunet.com/
v4->v5: add synchronize after migrate and delete it inside a lock
- split xfrm_state_migrate into create and install functions
Link to v4: https://lore.kernel.org/all/cover.1768811736.git.antony.antony@secunet.com/
v3->v4: add patch to fix pre-existing missing __rcu annotation on nlsk
v2->v3: - fix commit message formatting
v1->v2: dropped 6/6. That check is already there where the func is called
- merged patch 4/6 and 5/6, to fix use uninitialized value
- fix commit messages
---
---
Antony Antony (14):
xfrm: remove redundant assignments
xfrm: add extack to xfrm_init_state
xfrm: allow migration from UDP encapsulated to non-encapsulated ESP
xfrm: fix NAT-related field inheritance in SA migration
xfrm: rename reqid in xfrm_migrate
xfrm: split xfrm_state_migrate into create and install functions
xfrm: check family before comparing addresses in migrate
xfrm: add state synchronization after migration
xfrm: add error messages to state migration
xfrm: move encap and xuo into struct xfrm_migrate
xfrm: refactor XFRMA_MTIMER_THRESH validation into a helper
xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
xfrm: restrict netlink attributes for XFRM_MSG_MIGRATE_STATE
xfrm: add documentation for XFRM_MSG_MIGRATE_STATE
Documentation/networking/xfrm/index.rst | 1 +
.../networking/xfrm/xfrm_migrate_state.rst | 231 ++++++++++++++
include/net/xfrm.h | 78 ++++-
include/uapi/linux/xfrm.h | 21 ++
net/ipv4/ipcomp.c | 2 +-
net/ipv6/ipcomp6.c | 2 +-
net/key/af_key.c | 12 +-
net/xfrm/xfrm_device.c | 2 +-
net/xfrm/xfrm_policy.c | 27 +-
net/xfrm/xfrm_state.c | 144 +++++----
net/xfrm/xfrm_user.c | 338 ++++++++++++++++++++-
security/selinux/nlmsgtab.c | 3 +-
12 files changed, 764 insertions(+), 97 deletions(-)
---
base-commit: a77d172177f3754ebd70123c78c75a6efa9eec2a
change-id: migrate-state-063ee0342680
Best regards,
--
Antony Antony <antony.antony@secunet.com>
^ permalink raw reply
* [PATCH ipsec-next v8 01/14] xfrm: remove redundant assignments
From: Antony Antony @ 2026-05-05 4:31 UTC (permalink / raw)
To: Antony Antony, Steffen Klassert, Herbert Xu, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Masahide NAKAMURA, Paul Moore, Stephen Smalley,
Ondrej Mosnacek, Jonathan Corbet, Shuah Khan
Cc: Sabrina Dubroca, netdev, linux-kernel, selinux, linux-doc,
Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-0-4578fb016965@secunet.com>
These assignments are overwritten within the same function further down
commit e8961c50ee9cc ("xfrm: Refactor migration setup
during the cloning process")
x->props.family = m->new_family;
Which actually moved it in the
commit e03c3bba351f9 ("xfrm: Fix xfrm migrate issues when address family changes")
And the initial
commit 80c9abaabf428 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
added x->props.saddr = orig->props.saddr; and
memcpy(&xc->props.saddr, &m->new_saddr, sizeof(xc->props.saddr));
Signed-off-by: Antony Antony <antony.antony@secunet.com>
---
v1->v2: remove extra saddr copy, previous line
---
net/xfrm/xfrm_state.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 1748d374abca..9417a025270c 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1980,8 +1980,6 @@ static struct xfrm_state *xfrm_state_clone_and_setup(struct xfrm_state *orig,
x->props.mode = orig->props.mode;
x->props.replay_window = orig->props.replay_window;
x->props.reqid = orig->props.reqid;
- x->props.family = orig->props.family;
- x->props.saddr = orig->props.saddr;
if (orig->aalg) {
x->aalg = xfrm_algo_auth_clone(orig->aalg);
--
2.47.3
^ permalink raw reply related
* [PATCH ipsec-next v8 02/14] xfrm: add extack to xfrm_init_state
From: Antony Antony @ 2026-05-05 4:32 UTC (permalink / raw)
To: Antony Antony, Steffen Klassert, Herbert Xu, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Masahide NAKAMURA, Paul Moore, Stephen Smalley,
Ondrej Mosnacek, Jonathan Corbet, Shuah Khan
Cc: Sabrina Dubroca, netdev, linux-kernel, selinux, linux-doc,
Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-0-4578fb016965@secunet.com>
Add a struct extack parameter to xfrm_init_state() and pass it
through to __xfrm_init_state(). This allows validation errors detected
during state initialization to propagate meaningful error messages back
to userspace.
xfrm_state_migrate_create() now passes extack so that errors from the
XFRM_MSG_MIGRATE_STATE path are properly reported. Callers without an
extack context (af_key, ipcomp4, ipcomp6) pass NULL, preserving their
existing behaviour.
Signed-off-by: Antony Antony <antony.antony@secunet.com>
---
v5->v6: added this patch
---
include/net/xfrm.h | 2 +-
net/ipv4/ipcomp.c | 2 +-
net/ipv6/ipcomp6.c | 2 +-
net/key/af_key.c | 2 +-
net/xfrm/xfrm_state.c | 6 +++---
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 10d3edde6b2f..0c035955d87d 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1774,7 +1774,7 @@ u32 xfrm_replay_seqhi(struct xfrm_state *x, __be32 net_seq);
int xfrm_init_replay(struct xfrm_state *x, struct netlink_ext_ack *extack);
u32 xfrm_state_mtu(struct xfrm_state *x, int mtu);
int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack);
-int xfrm_init_state(struct xfrm_state *x);
+int xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack);
int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type);
int xfrm_input_resume(struct sk_buff *skb, int nexthdr);
int xfrm_trans_queue_net(struct net *net, struct sk_buff *skb,
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index 9a45aed508d1..b1ea2d37e8c5 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -77,7 +77,7 @@ static struct xfrm_state *ipcomp_tunnel_create(struct xfrm_state *x)
memcpy(&t->mark, &x->mark, sizeof(t->mark));
t->if_id = x->if_id;
- if (xfrm_init_state(t))
+ if (xfrm_init_state(t, NULL))
goto error;
atomic_set(&t->tunnel_users, 1);
diff --git a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c
index 8607569de34f..b340d67eb1d9 100644
--- a/net/ipv6/ipcomp6.c
+++ b/net/ipv6/ipcomp6.c
@@ -95,7 +95,7 @@ static struct xfrm_state *ipcomp6_tunnel_create(struct xfrm_state *x)
memcpy(&t->mark, &x->mark, sizeof(t->mark));
t->if_id = x->if_id;
- if (xfrm_init_state(t))
+ if (xfrm_init_state(t, NULL))
goto error;
atomic_set(&t->tunnel_users, 1);
diff --git a/net/key/af_key.c b/net/key/af_key.c
index a166a88d8788..842bf5786e3f 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -1299,7 +1299,7 @@ static struct xfrm_state * pfkey_msg2xfrm_state(struct net *net,
}
}
- err = xfrm_init_state(x);
+ err = xfrm_init_state(x, NULL);
if (err)
goto out;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9417a025270c..53d88b87bdbd 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2143,7 +2143,7 @@ struct xfrm_state *xfrm_state_migrate(struct xfrm_state *x,
if (!xc)
return NULL;
- if (xfrm_init_state(xc) < 0)
+ if (xfrm_init_state(xc, extack) < 0)
goto error;
/* configure the hardware if offload is requested */
@@ -3238,11 +3238,11 @@ int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack)
EXPORT_SYMBOL(__xfrm_init_state);
-int xfrm_init_state(struct xfrm_state *x)
+int xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack)
{
int err;
- err = __xfrm_init_state(x, NULL);
+ err = __xfrm_init_state(x, extack);
if (err)
return err;
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox