* Re: [PATCH v4 5/7] ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI flash
From: Linus Walleij @ 2026-06-30 22:27 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
michael, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20260630092406.150587-6-manikandan.m@microchip.com>
On Tue, Jun 30, 2026 at 11:26 AM Manikandan Muralidharan
<manikandan.m@microchip.com> wrote:
> Move the QSPI flash partitions under a "partitions" node with the
> "fixed-partitions" compatible, as required by the current MTD partition
> binding, instead of declaring them as direct children of the flash node.
> No functional change.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: dsa: motorcomm: Add LED support
From: Andrew Lunn @ 2026-06-30 22:25 UTC (permalink / raw)
To: David Yang
Cc: netdev, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260629183137.541341-5-mmyangfl@gmail.com>
> + duty_req = YT921X_LED_DUTY(on > off ? off : on, cycle_req);
> + for (unsigned int i = ARRAY_SIZE(dutys) - 1;; i--)
> + if (i <= 0 || duty_req >= (dutys[i - 1] + dutys[i]) / 2) {
> + duty = dutys[i];
> + break;
> + }
The ;; got the looking at this, since it is unusual.
i is an unsigned int, so it can never be < 0. The test should be just
i == 0.
> +static int
> +yt921x_led_blink_set(struct yt921x_priv *priv, int port, int group,
> + unsigned long *onp, unsigned long *offp)
> +{
> + struct yt921x_port *pp = priv->ports[port];
> + struct yt921x_led *led;
> + unsigned short cycle;
> + unsigned short duty;
> + bool change_cycle;
> + bool change_duty;
> + bool use_cycle;
> + u32 ctrl;
> + u32 mask;
> + u32 val;
> + int res;
> +
> + if (!pp)
> + return -ENODEV;
I really do dislike all the tests.
Are LEDs created if pp is NULL?
Please don't use defensive programming, understand the logic of the
code and decide if this can happen. If it can, then yes, have the
test. If however yt921x_leds_setup() has this test, and will never
create and register LEDs with the LED code if pp is NULL, you don't
need any of these tests. Please look at every instance of such tests
and really consider, can it happen?
Andrew
^ permalink raw reply
* Re: [PATCH v4 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
From: Linus Walleij @ 2026-06-30 22:25 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
michael, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20260630092406.150587-4-manikandan.m@microchip.com>
Hi Manikandan,
thanks for your patch!
On Tue, Jun 30, 2026 at 11:25 AM Manikandan Muralidharan
<manikandan.m@microchip.com> wrote:
> Register the cached SFDP as a read-only NVMEM device rooted at the
> flash's "sfdp" child node, exposing it in on-flash byte order. This lets
> NVMEM cells reference any SFDP data: a fixed-layout for parameters at a
> known offset, or an nvmem-layout parser for vendor data whose location
> must be discovered at runtime. The device is only registered when an
> "sfdp" node is present in the device tree.
It seems the existing serial NOR driver core already reads out the SFDP
and stores it in nor->sfdp->dwords, right?
This should be mentioned in the commit so we know when the stuff
is actually read in from the flash memory.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
(...)
> @@ -3204,6 +3204,11 @@ static int spi_nor_init_params(struct spi_nor *nor)
> spi_nor_init_params_deprecated(nor);
> }
>
> + /* Expose the SFDP as an NVMEM device. */
Add "if and only if the flash has an SFDP"
> +static int spi_nor_sfdp_nvmem_read(void *priv, unsigned int offset,
> + void *val, size_t bytes)
Name it _reg_read() to mirror the nvmem prototype.
> +/**
> + * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
> + * @nor: pointer to a 'struct spi_nor'
> + *
> + * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
> + * rooted at the flash's "sfdp" child node. This lets generic (fixed-layout) or
> + * vendor (nvmem-layout) cells reference any SFDP data. The device is only
> + * registered when an "sfdp" node is described in the device tree.
> + *
> + * Return: 0 on success or if there is nothing to do, -errno otherwise.
> + */
> +int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
> +{
> + struct device *dev = nor->dev;
> + struct nvmem_config config = { };
> + struct nvmem_device *nvmem;
> + struct device_node *np;
> + int ret;
> +
> + if (!nor->sfdp)
> + return 0;
> +
> + np = of_get_child_by_name(dev_of_node(dev), "sfdp");
> + if (!np)
> + return 0;
If this node name is required to be named like that it has to be
enforced in the schema.
I would instead check all the nodes (for_each_available_child)
for the right compatible "jedec,sfdp".
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 6.6.y] af_unix: Set gc_in_progress to true in unix_gc().
From: Sasha Levin @ 2026-06-30 22:23 UTC (permalink / raw)
To: stable
Cc: Sasha Levin, Kuniyuki Iwashima, Jakub Kicinski, Paolo Abeni,
David S . Miller, Eric Dumazet, netdev, Igor Ushakov
In-Reply-To: <20260629093954.195016-1-sysroot314@gmail.com>
> [ move WRITE_ONCE(gc_in_progress, true) into the __unix_gc() work function and drop it from unix_gc(). ]
Dropping the set from unix_gc() and doing it in the work function is fine
upstream, but only because later refactors made wait_for_unix_gc() gate
flush_work() on unix_graph_cyclic_sccs. On these trees it still gates on
gc_in_progress, so this brings back a window where the over-limit throttle
stops waiting for GC.
Can you respin keeping gc_in_progress set in unix_gc() before queue_work()?
The code is identical across all three, so one version covers them.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect
From: Lorenzo Bianconi @ 2026-06-30 22:16 UTC (permalink / raw)
To: Stanislav Fomichev
Cc: Vladimir Vdovin, bpf, netdev, ast, daniel, andrii, martin.lau,
sdf, hawk, john.fastabend, kuba
In-Reply-To: <akQyT2d0wNF5F5LG@devvm7509.cco0.facebook.com>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
On Jun 30, Stanislav Fomichev wrote:
> On 06/30, Vladimir Vdovin wrote:
> > This series lets XDP programs work with the hardware RX checksum verdict:
> > read what the NIC concluded about a packet, and carry a "the L4 checksum
> > is correct" assertion across a redirect so the stack does not revalidate
> > it in software.
> >
> > When an XDP program redirects a frame to a cpumap (or any other path that
> > rebuilds an skb from an xdp_frame via __xdp_build_skb_from_frame()), the
> > HW RX checksum status is lost and the stack revalidates the L4 checksum in
> > software.
> >
> > Two kfuncs are added:
> >
> > - bpf_xdp_metadata_rx_csum(): a device-bound RX-metadata hint, like the
> > existing rx_hash / rx_vlan_tag ones. It reports enum xdp_csum_status
> > (XDP_CSUM_NONE / XDP_CSUM_VERIFIED) and is implemented for mlx5e, ice
> > and veth.
> >
> > - bpf_xdp_assert_rx_csum(): a generic, non-device-bound kfunc that lets
> > the program assert the L4 checksum is correct. It sets a buff flag
> > that rides into the xdp_frame, and __xdp_build_skb_from_frame() turns
> > it into skb->ip_summed = CHECKSUM_UNNECESSARY. The kernel cannot
> > verify the assertion; the program takes responsibility, as it already
> > does when rewriting packet contents.
> >
> > Posted as RFC to get feedback on:
> >
> > - whether the read hint (bpf_xdp_metadata_rx_csum() and its driver
> > support) belongs in this series at all. bpf_xdp_assert_rx_csum() is
> > self-contained and already covers the main use case: a program that
> > computes or fixes the L4 checksum itself, or trusts the source, and
> > wants the rebuilt skb to skip software revalidation. The read hint is
> > an optimization for programs that did not touch the payload and only
> > want to relay the hardware verdict. These could just as well be two
> > independent series (assert-only first);
> > - the kfunc naming, bpf_xdp_assert_rx_csum() in particular.
> >
> > Testing:
> >
> > - new selftest xdp_cpumap_rx_csum drives a frame through a native-XDP
> > veth into a cpumap redirect and checks, via fexit on
> > __xdp_build_skb_from_frame(), that the rebuilt skb is
> > CHECKSUM_UNNECESSARY iff the program called bpf_xdp_assert_rx_csum();
> > - xdp_metadata calls bpf_xdp_metadata_rx_csum() over veth and checks both
> > verdicts: XDP_CSUM_NONE for an AF_XDP-injected frame and
> > XDP_CSUM_VERIFIED for one sent through the stack.
>
> This was posted somewhat recently from Lorenzo (and had a fair bit of
> discussion), but there haven't been a follow up:
> https://lore.kernel.org/bpf/20260217-bpf-xdp-meta-rxcksum-v3-0-30024c50ba71@kernel.org/
Hi Vladimir and Stanislav,
AFAIK in my series we are just missing the drv self-test requested by Jakub.
I have not the time to look into it yet.
@Vladimir: if you have any free-cycles, do you agree to introduce the missing
test requested by Jakub to my series? Thanks in advance.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Linus Walleij @ 2026-06-30 22:12 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
michael, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20260630092406.150587-2-manikandan.m@microchip.com>
Hi Manikandan,
thanks for your patch!
On Tue, Jun 30, 2026 at 11:24 AM Manikandan Muralidharan
<manikandan.m@microchip.com> wrote:
> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
> contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
I would expect it to follow nvmem conventions like this, notice
compatibles specific-to-general with sfdp first:
sfdp {
/* NVMEM provided by SFDP */
compatible = "jedec,sfdp", "nvmem-cells";
label = "SFDP";
read-only;
#address-cells = <1>;
#size-cells = <1>;
mac0: macaddr@0x00 {
reg = <0x00 0x06>;
};
mac1: macaddr@0x06 {
reg = <0x06 0x06>;
};
};
Your example should definitely be more elaborate like this,
just an opaque sfdp node will not suffice. Maybe a separate
example?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] net: dsa: motorcomm: Dynamically allocate port structures
From: Andrew Lunn @ 2026-06-30 22:12 UTC (permalink / raw)
To: David Yang
Cc: netdev, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260629183137.541341-4-mmyangfl@gmail.com>
On Tue, Jun 30, 2026 at 02:31:34AM +0800, David Yang wrote:
> With support for LED introduced later, struct yt921x_priv will be 17k
> which is not very good for a single kmalloc(). Convert the ports array
> to a array of pointers to stop bloating the priv struct.
>
> Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] net: dsa: motorcomm: Split SMI module
From: Andrew Lunn @ 2026-06-30 22:12 UTC (permalink / raw)
To: David Yang
Cc: netdev, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260629183137.541341-3-mmyangfl@gmail.com>
On Tue, Jun 30, 2026 at 02:31:33AM +0800, David Yang wrote:
> SMI operations are going to be used across different modules.
>
> Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/4] net: dsa: motorcomm: Move to subdirectory
From: Andrew Lunn @ 2026-06-30 22:10 UTC (permalink / raw)
To: David Yang
Cc: netdev, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <20260629183137.541341-2-mmyangfl@gmail.com>
On Tue, Jun 30, 2026 at 02:31:32AM +0800, David Yang wrote:
> yt921x is already the longest single-file DSA driver, so it's time to
> split it into parts.
>
> Signed-off-by: David Yang <mmyangfl@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 13/13] gpiolib: remove linux/gpio.h
From: Philippe Mathieu-Daudé @ 2026-06-30 22:09 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-14-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> After all other drivers have converted to linux/gpio/consumer.h
> or linux/gpio/legacy.h, remove the final leftover bits here.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> MAINTAINERS | 1 -
> drivers/gpio/TODO | 4 +---
> drivers/gpio/gpiolib-cdev.c | 2 +-
> drivers/gpio/gpiolib-legacy.c | 3 +--
> drivers/gpio/gpiolib.c | 2 +-
> include/linux/gpio.h | 22 ----------------------
> 6 files changed, 4 insertions(+), 30 deletions(-)
> delete mode 100644 include/linux/gpio.h
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next v7 4/4] net: phy: realtek: load firmware for RTL8261C_CG
From: Andrew Lunn @ 2026-06-30 22:09 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean, nic_swsd
In-Reply-To: <20260629064718.1349-5-javen_xu@realsil.com.cn>
On Mon, Jun 29, 2026 at 02:47:18PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds support for loading firmware. Download some parameters
> for RTL8261C_CG.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
> ---
> Changes in v2:
> - remove __pack, struct rtl8261x_fw_header and rtl8261x_fw_entry will not pad
> - reverse xmas tree for some definition
> - add explanation on rtl_phy_write_mmd_bits()
>
> Changes in v3:
> - add struct rtl8261x_priv
>
> Changes in v4:
> - add struct device *dev
>
> Changes in v5:
> - no changes
>
> Changes in v6:
> - replace rtl_phy_write_mmd_bits with phy_modify_mmd, keep mdio lock
> - check msb and lsb at the beginning of rtl8261x_fw_execute_entry()
> - add comments on rtl8261x_config_init()
>
> Changes in v7:
> - no changes
> ---
> drivers/net/phy/realtek/realtek_main.c | 220 +++++++++++++++++++++++++
> 1 file changed, 220 insertions(+)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index ef3700894ebf..bf7bc19fb44c 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -8,7 +8,9 @@
> * Copyright (c) 2004 Freescale Semiconductor, Inc.
> */
> #include <linux/bitops.h>
> +#include <linux/crc32.h>
> #include <linux/ethtool_netlink.h>
> +#include <linux/firmware.h>
> #include <linux/of.h>
> #include <linux/phy.h>
> #include <linux/pm_wakeirq.h>
> @@ -281,6 +283,42 @@
> RTL8261X_INT_ALDPS_CHG | \
> RTL8261X_INT_JABBER)
>
> +#define FW_MAIN_MAGIC 0x52544C38
> +#define FW_SUB_MAGIC_8261C 0x32363143
> +#define RTL8261X_POLL_TIMEOUT_MS 100
> +
> +#define RTL8261C_CE_FW_NAME "rtl_nic/rtl8261c.bin"
> +MODULE_FIRMWARE(RTL8261C_CE_FW_NAME);
> +
> +enum rtl8261x_fw_op {
> + OP_WRITE = 0x00, /* Write */
> + OP_POLL = 0x02, /* Polling */
> +};
> +
> +struct rtl8261x_fw_header {
> + __le32 main_magic; /* Main magic number 0x52544C38 ("RTL8") */
> + __le32 sub_magic; /* Sub magic number */
> + __le16 version_major; /* Major version */
> + __le16 version_minor; /* Minor version */
> + __le16 num_entries; /* Number of entries */
> + __le16 reserved; /* Reserved */
> + __le32 crc32; /* CRC32 checksum */
> +};
> +
> +struct rtl8261x_fw_entry {
> + __u8 type; /* Operation type (OP_*) */
> + __u8 dev; /* MMD device */
> + __le16 addr; /* Register address */
> + __u8 msb; /* MSB bit position */
> + __u8 lsb; /* LSB bit position */
> + __le16 value; /* Value to write/compare */
> + __le16 timeout_ms; /* Poll timeout in milliseconds */
> + __u8 poll_set; /* Poll for set (1) or clear (0) */
> + __u8 reserved; /* Reserved */
> +};
Are there other devices which need firmware download? Do they use the
same header? I'm just wondering if this will be reused by other
devices?
Andrew
^ permalink raw reply
* Re: [PATCH 04/13] sh: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-5-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> linux/gpio/legacy.h for the sh boards using the legacy interfaces,
> or remove it where it is not needed at all.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/sh/boards/board-magicpanelr2.c | 2 +-
> arch/sh/boards/board-sh7757lcr.c | 2 +-
> arch/sh/boards/board-urquell.c | 2 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> arch/sh/boards/mach-highlander/pinmux-r7785rp.c | 2 +-
> arch/sh/boards/mach-kfr2r09/lcd_wqvga.c | 2 +-
> arch/sh/boards/mach-kfr2r09/setup.c | 2 +-
> arch/sh/boards/mach-migor/lcd_qvga.c | 2 +-
> arch/sh/boards/mach-migor/setup.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
> arch/sh/boards/mach-rsk/devices-rsk7269.c | 1 -
> arch/sh/boards/mach-se/7724/setup.c | 2 +-
> arch/sh/include/mach-common/mach/magicpanelr2.h | 2 --
> arch/sh/kernel/cpu/sh4a/setup-shx3.c | 2 +-
> 15 files changed, 13 insertions(+), 16 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 03/13] mips: replace linux/gpio.h inclusions
From: Philippe Mathieu-Daudé @ 2026-06-30 22:08 UTC (permalink / raw)
To: Arnd Bergmann, linux-gpio
Cc: Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-4-arnd@kernel.org>
On 29/6/26 15:26, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> linux/gpio.h should no longer be used, convert these instead to
> either linux/gpio/consumer.h or linux/gpio/legacy.h as needed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/mips/alchemy/board-xxs1500.c | 2 +-
> arch/mips/alchemy/devboards/db1000.c | 2 +-
> arch/mips/alchemy/devboards/db1200.c | 2 +-
> arch/mips/alchemy/devboards/db1550.c | 2 +-
> arch/mips/bcm47xx/workarounds.c | 2 +-
> arch/mips/bcm63xx/boards/board_bcm963xx.c | 1 +
> arch/mips/include/asm/mach-bcm63xx/board_bcm963xx.h | 2 +-
> arch/mips/txx9/rbtx4927/setup.c | 2 +-
> 8 files changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next v7 3/4] net: phy: realtek: add support for RTL8261C_CG
From: Andrew Lunn @ 2026-06-30 22:05 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean, nic_swsd
In-Reply-To: <20260629064718.1349-4-javen_xu@realsil.com.cn>
On Mon, Jun 29, 2026 at 02:47:17PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds support for Realtek phy chip RTL8261C_CG. Its PHY ID is
> 0x001cc898.
> This patch introduces a distinct family of handlers (probe, get_features,
> config_aneg, read_status, config_intr, handle_interrupt).
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v7 2/4] net: phy: c45: add setup and read master/slave helpers
From: Andrew Lunn @ 2026-06-30 22:03 UTC (permalink / raw)
To: javen
Cc: hkallweit1, linux, davem, edumazet, kuba, pabeni, freddy_gu, nb,
netdev, linux-kernel, daniel, vladimir.oltean, nic_swsd
In-Reply-To: <20260629064718.1349-3-javen_xu@realsil.com.cn>
On Mon, Jun 29, 2026 at 02:47:16PM +0800, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> This patch adds two static helpers in drivers/net/phy/phy-c45.c to
> configure and read back master-slave roles for non BASE-T1 Clause 45
> PHYs via the 10GBASE-T AN control/status registers.
> These helpers are wired into genphy_c45_config_aneg() and
> genphy_c45_read_status(). This changes the observable ethtool output
> for drivers using the generic c45 read path.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] mac802154: wait for RCU readers when removing interfaces
From: Kuniyuki Iwashima @ 2026-06-30 21:46 UTC (permalink / raw)
To: alhouseenyousef
Cc: alex.aring, davem, edumazet, horms, kuba, linux-kernel,
linux-wpan, marcel, miquel.raynal, netdev, pabeni, stable, stefan,
syzbot+36256deb69a588e9290e
In-Reply-To: <20260630211808.50440-1-alhouseenyousef@gmail.com>
From: Yousef Alhouseen <alhouseenyousef@gmail.com>
Date: Tue, 30 Jun 2026 23:18:08 +0200
> Queue wake, stop, and disable paths walk local->interfaces under RCU.
> The bulk hardware teardown path removes entries with list_del() and
The problematic part is list_del(), not unregister_netdevice().
> immediately unregisters their netdevices, so an asynchronous transmit
not immediately, unregister_netdevice() waits inflight RCU readers.
So, synchronize_rcu() should be unnecessary.
(Same remark for ieee802154_if_remove())
> completion can follow a poisoned list node in ieee802154_wake_queue().
>
> Match ieee802154_if_remove(): use list_del_rcu() and wait for existing
> readers before unregistering each interface.
>
> Fixes: 592dfbfc72f5 ("mac820154: move interface unregistration into iface")
> Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e
> Cc: stable@vger.kernel.org
> Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
> ---
> net/mac802154/iface.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
> index 000be60d9580..73d82a015184 100644
> --- a/net/mac802154/iface.c
> +++ b/net/mac802154/iface.c
> @@ -703,7 +703,8 @@ void ieee802154_remove_interfaces(struct ieee802154_local *local)
>
> mutex_lock(&local->iflist_mtx);
> list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
> - list_del(&sdata->list);
> + list_del_rcu(&sdata->list);
> + synchronize_rcu();
>
> unregister_netdevice(sdata->dev);
> }
> --
^ permalink raw reply
* Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Rob Herring @ 2026-06-30 21:45 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Christian Marangi, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, stable, Bartosz Golaszewski
In-Reply-To: <CAFEp6-163adAq8-H_pCzGnq+Fo4jpyKGs6Jv25j3fSpZg3COjQ@mail.gmail.com>
On Tue, Jun 30, 2026 at 2:59 PM Loic Poulain
<loic.poulain@oss.qualcomm.com> wrote:
>
> Hi Rob,
>
> On Tue, Jun 30, 2026 at 8:02 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> > > Child nodes of a fixed-partitions node are not necessarily partition
> > > entries, for example an nvmem-layout node has no reg property. The
> > > current code passes a NULL reg pointer and uninitialized len to the
> > > length check, which can result in a kernel panic or silent failure to
> > > register any partitions.
> >
> > That does not sound right to me. A fixed-partitions node should only be
> > defining partitions with address ranges. I would expect a partition node
> > could be nvmem-layout, but not the whole address range. If you wanted
> > the latter, then just do:
> >
> > partitions {
> > ...
> > };
> >
> > nvmem-layout {
> > ...
> > };
>
> In our case, the nvmem-layout needs to be associated with a specific
> eMMC hardware partition, nvmem cells can be a simple sub-range within
> the global eMMC, each hardware partition (boot0, boot1, user...)
> having its own address spaces.
>
> That said, your point about not abusing fixed-partitions is valid. I
> initially dropped the compatible = "fixed-partitions" from the
> partitions-boot1 node when it only carries an nvmem-layout and no
> actual partition entries, making it a plain named container node. But
> it's a bit fragile if we want to support both nvmem-layout and
> fixed-partitions.
>
> Regarding your expectation of a partition node being a nvmem-layout,
> do you mean that the nvmem-layout should live under a fixed-partitions
> node? Something along these lines:
>
> partitions-boot1 {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> nvmem@4400 {
partition@4400
> reg = <0x4400 0x1000>;
>
> nvmem-layout {
> compatible = "fixed-layout";
> #address-cells = <1>;
> #size-cells = <1>;
>
> wifi_mac_addr: mac-addr@0 {
> compatible = "mac-base";
> reg = <0x0 0x6>;
> #nvmem-cell-cells = <1>;
> };
> [...]
Either this or replacing "fixed-partitions" with "fixed-layout" if you
want to make the whole boot1 partition nvmem-layout looks like the
right way to me.
> That makes some sense, this would require extra work for the
> emmc/block layer to also associate fwnodes with logical partitions,
> not just the whole disk/hw (hw part), Is that the direction you'd like
> us to go?
Yes.
> Also, Note that regardless of which approach we settle on, this
> specific fix/patch remains necessary to validate the partition node
> and prevent NULL-deref.
Fair enough, though the reasoning for it would be different and
perhaps should give a warning.
Rob
^ permalink raw reply
* [PATCH net 4/4] igbvf: Fix leak in TX DMA error cleanup
From: Tony Nguyen @ 2026-06-30 21:44 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Matt Vollrath, anthony.l.nguyen, stable
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: Matt Vollrath <tactii@gmail.com>
If an error is encountered while mapping TX buffers, the driver should
unmap any buffers already mapped for that skb.
Because count is incremented before each frag mapping, it will always
match the correct number of unmappings needed when dma_error is reached.
Decrementing count before the while loop in dma_error causes an
off-by-one error. If any mapping was successful before an unsuccessful
mapping, exactly one DMA mapping (the head) would leak.
This bug was introduced by a 2010 fix for an endless loop in dma_error.
All other affected drivers have already been fixed.
Fixes: c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-4-7-opus
Signed-off-by: Matt Vollrath <tactii@gmail.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 0a3d0a1cba43..c686ee120a14 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2190,8 +2190,6 @@ static inline int igbvf_tx_map_adv(struct igbvf_adapter *adapter,
buffer_info->time_stamp = 0;
buffer_info->length = 0;
buffer_info->mapped_as_page = false;
- if (count)
- count--;
/* clear timestamp and dma mappings for remaining portion of packet */
while (count--) {
--
2.47.1
^ permalink raw reply related
* [PATCH net 3/4] idpf: handle NULL adev in idpf_idc_vdev_mtu_event
From: Tony Nguyen @ 2026-06-30 21:44 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: David Carlier, anthony.l.nguyen, tatyana.e.nikolova, joshua.a.hay,
horms, stable, Aleksandr Loktionov, Jakub Andrysiak
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: David Carlier <devnexen@gmail.com>
idpf_idc_vport_dev_ctrl(adapter, false) clears vport->vdev_info->adev
to NULL but keeps vport->vdev_info itself. An MTU change after that
calls idpf_idc_vdev_mtu_event(), which dereferences vdev_info->adev for
device_lock() before reaching the (!adev || ...) check.
Cache vdev_info->adev once with READ_ONCE() and bail out if NULL before
locking. Use the cached pointer on both the lock and unlock paths so
the unlock matches the device actually acquired and cannot re-fetch a
NULL slot.
Fixes: ed6e1c8796a4 ("idpf: implement IDC vport aux driver MTU change handler")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Jakub Andrysiak <jakub.andrysiak@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_idc.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c
index b7d6b08fc89e..9f764135507c 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
@@ -162,9 +162,12 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
set_bit(event_type, event.type);
- device_lock(&vdev_info->adev->dev);
- adev = vdev_info->adev;
- if (!adev || !adev->dev.driver)
+ adev = READ_ONCE(vdev_info->adev);
+ if (!adev)
+ return;
+
+ device_lock(&adev->dev);
+ if (!adev->dev.driver)
goto unlock;
iadrv = container_of(adev->dev.driver,
struct iidc_rdma_vport_auxiliary_drv,
@@ -172,7 +175,7 @@ void idpf_idc_vdev_mtu_event(struct iidc_rdma_vport_dev_info *vdev_info,
if (iadrv->event_handler)
iadrv->event_handler(vdev_info, &event);
unlock:
- device_unlock(&vdev_info->adev->dev);
+ device_unlock(&adev->dev);
}
/**
--
2.47.1
^ permalink raw reply related
* [PATCH net 2/4] ice: fix VF interrupts cleanup
From: Tony Nguyen @ 2026-06-30 21:44 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Dawid Osuchowski, anthony.l.nguyen, stable, Vladimir Medvedkin,
Aleksandr Loktionov, Simon Horman, Patryk Holda
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
When a virtual function sends an IRQ map command, the PF will set up
interrupts according to that request. However, because these interrupts are
never reset, the next time Virtual Function initializes, the interrupts are
still enabled for a given VF, which leads to performance degradation in
certain cases due to interrupts being unexpectedly enabled and thus causing
interrupt floods.
Cc: stable@vger.kernel.org
Fixes: 1071a8358a28 ("ice: Implement virtchnl commands for AVF support")
Suggested-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Patryk Holda <patryk.holda@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 27 +++++++++++++++++++
.../ethernet/intel/ice/ice_vf_lib_private.h | 1 +
drivers/net/ethernet/intel/ice/virt/queues.c | 21 +++++++++++++++
3 files changed, 49 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index 27e4acb1620f..7ce8f66eebbf 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -847,6 +847,30 @@ static void ice_notify_vf_reset(struct ice_vf *vf)
NULL);
}
+/**
+ * ice_reset_interrupts - clear all queue interrupt configuration for a VSI
+ * @vsi: the VSI whose interrupt registers should be cleared
+ *
+ * Zero the QINT_RQCTL and QINT_TQCTL registers for all allocated queues
+ * in the VSI. This clears the entire register including MSIX_INDX, ITR_INDX,
+ * CAUSE_ENA and NEXTQ fields, unlike ice_vf_dis_rxq_interrupt() which only
+ * clears the CAUSE_ENA bit.
+ */
+void ice_reset_interrupts(struct ice_vsi *vsi)
+{
+ struct ice_pf *pf = vsi->back;
+ struct ice_hw *hw = &pf->hw;
+ int i;
+
+ ice_for_each_alloc_rxq(vsi, i)
+ wr32(hw, QINT_RQCTL(vsi->rxq_map[i]), 0);
+
+ ice_for_each_alloc_txq(vsi, i)
+ wr32(hw, QINT_TQCTL(vsi->txq_map[i]), 0);
+
+ ice_flush(hw);
+}
+
/**
* ice_reset_vf - Reset a particular VF
* @vf: pointer to the VF structure
@@ -918,6 +942,9 @@ int ice_reset_vf(struct ice_vf *vf, u32 flags)
ice_dis_vf_qs(vf);
+ /* cleanup interrupt registers */
+ ice_reset_interrupts(vsi);
+
/* Call Disable LAN Tx queue AQ whether or not queues are
* enabled. This is needed for successful completion of VFR.
*/
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h b/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h
index 5392b0404986..321d29c25b7c 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib_private.h
@@ -26,6 +26,7 @@
void ice_initialize_vf_entry(struct ice_vf *vf);
void ice_deinitialize_vf_entry(struct ice_vf *vf);
void ice_dis_vf_qs(struct ice_vf *vf);
+void ice_reset_interrupts(struct ice_vsi *vsi);
int ice_check_vf_init(struct ice_vf *vf);
enum virtchnl_status_code ice_err_to_virt_err(int err);
struct ice_port_info *ice_vf_get_port_info(struct ice_vf *vf);
diff --git a/drivers/net/ethernet/intel/ice/virt/queues.c b/drivers/net/ethernet/intel/ice/virt/queues.c
index 31be2f76181c..431c9c546b04 100644
--- a/drivers/net/ethernet/intel/ice/virt/queues.c
+++ b/drivers/net/ethernet/intel/ice/virt/queues.c
@@ -224,6 +224,24 @@ void ice_vf_ena_rxq_interrupt(struct ice_vsi *vsi, u32 q_idx)
wr32(hw, QINT_RQCTL(pfq), reg | QINT_RQCTL_CAUSE_ENA_M);
}
+/**
+ * ice_vf_dis_rxq_interrupt - disable Rx queue interrupt via QINT_RQCTL
+ * @vsi: VSI of the VF to configure
+ * @q_idx: VF queue index used to determine the queue in the PF's space
+ */
+static void ice_vf_dis_rxq_interrupt(struct ice_vsi *vsi, u32 q_idx)
+{
+ struct ice_hw *hw = &vsi->back->hw;
+ u32 pfq = vsi->rxq_map[q_idx];
+ u32 reg;
+
+ reg = rd32(hw, QINT_RQCTL(pfq));
+ reg &= ~QINT_RQCTL_CAUSE_ENA_M;
+ wr32(hw, QINT_RQCTL(pfq), reg);
+
+ ice_flush(hw);
+}
+
/**
* ice_vc_ena_qs_msg
* @vf: pointer to the VF info
@@ -416,6 +434,8 @@ int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
goto error_param;
}
+ for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF)
+ ice_vf_dis_rxq_interrupt(vsi, vf_q_id);
bitmap_zero(vf->rxq_ena, ICE_MAX_RSS_QS_PER_VF);
} else if (q_map) {
for_each_set_bit(vf_q_id, &q_map, ICE_MAX_RSS_QS_PER_VF) {
@@ -436,6 +456,7 @@ int ice_vc_dis_qs_msg(struct ice_vf *vf, u8 *msg)
goto error_param;
}
+ ice_vf_dis_rxq_interrupt(vsi, vf_q_id);
/* Clear enabled queues flag */
clear_bit(vf_q_id, vf->rxq_ena);
}
--
2.47.1
^ permalink raw reply related
* [PATCH net 1/4] ice: wait for reset completion in ice_resume()
From: Tony Nguyen @ 2026-06-30 21:43 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev
Cc: Aaron Ma, anthony.l.nguyen, jbrandeb, stable, Kohei Enju,
Aleksandr Loktionov, Przemek Kitszel, Alexander Nowlin
In-Reply-To: <20260630214404.930923-1-anthony.l.nguyen@intel.com>
From: Aaron Ma <aaron.ma@canonical.com>
ice_resume() schedules an asynchronous PF reset and returns
immediately. The reset runs later in ice_service_task(). If
userspace tries to bring up the net device before the reset
finishes, ice_open() fails with -EBUSY:
ice_resume()
ice_schedule_reset() # sets ICE_PFR_REQ, returns
...
ice_open()
ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY
...
ice_service_task()
ice_do_reset()
ice_rebuild() # clears ICE_PFR_REQ, too late
Reproduced on E800 series NICs during suspend/resume with irdma
enabled, where the aux device probe widens the race window.
ice 0000:81:00.0: can't open net device while reset is in progress
Add a best-effort wait (10s timeout, matching ice_devlink_info_get())
for the reset to complete before returning from ice_resume(). In
practice the reset completes in ~300ms.
Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
Cc: stable@vger.kernel.org
Reviewed-by: Kohei Enju <kohei@enjuk.jp>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
---
drivers/net/ethernet/intel/ice/ice_main.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index e2fd2dab03e3..d88835482d3a 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5637,6 +5637,16 @@ static int ice_resume(struct device *dev)
/* Restart the service task */
mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf->serv_tmr_period));
+ /* Best-effort wait for the scheduled reset to finish so that the
+ * device is operational before returning. Without this, userspace
+ * (e.g. NetworkManager) may try to open the net device while the
+ * asynchronous reset is still in progress, hitting -EBUSY.
+ */
+ ret = ice_wait_for_reset(pf, secs_to_jiffies(10));
+ if (ret)
+ dev_err(dev, "Wait for reset timed out (10s) during resume: %d\n",
+ ret);
+
return 0;
}
--
2.47.1
^ permalink raw reply related
* [PATCH net 0/4][pull request] Intel Wired LAN Driver Updates 2026-06-30 (ice, idpf, igbvf)
From: Tony Nguyen @ 2026-06-30 21:43 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet, andrew+netdev, netdev; +Cc: Tony Nguyen
Aaron Ma adds a wait for reset completion before returning from resume
on ice driver.
Dawid completely disables and clears VF interrupts during reset on ice.
David Carlier adds handling for a NULL adev when reporting MTU change
event for idpf.
Matt Vollrath removes incorrect decrement of count which could cause
leaking due to off-by-one issue.
The following are changes since commit 2a00517db8de4be7df3d483b215c5544fb30a191:
bridge: stp: Fix a potential use-after-free when deleting a bridge
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue 100GbE
Aaron Ma (1):
ice: wait for reset completion in ice_resume()
David Carlier (1):
idpf: handle NULL adev in idpf_idc_vdev_mtu_event
Dawid Osuchowski (1):
ice: fix VF interrupts cleanup
Matt Vollrath (1):
igbvf: Fix leak in TX DMA error cleanup
drivers/net/ethernet/intel/ice/ice_main.c | 10 +++++++
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 27 +++++++++++++++++++
.../ethernet/intel/ice/ice_vf_lib_private.h | 1 +
drivers/net/ethernet/intel/ice/virt/queues.c | 21 +++++++++++++++
drivers/net/ethernet/intel/idpf/idpf_idc.c | 11 +++++---
drivers/net/ethernet/intel/igbvf/netdev.c | 2 --
6 files changed, 66 insertions(+), 6 deletions(-)
--
2.47.1
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Linus Walleij @ 2026-06-30 21:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Dmitry Torokhov, Jakub Kicinski,
Paolo Abeni, Dominik Brodowski, linux-kernel, linux-arm-kernel,
linux-samsung-soc, patches, linux-m68k, linux-mips, linux-sh,
linux-input, linux-media, netdev, linux-sunxi, linux-phy,
linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 3:26 PM Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
> or linux/gpio/legacy.h for the few remaining users of the old number
> based interface.
>
> All patches in this series can get applied independently, so my
> preference would be for each subsystem maintainer to apply these
> directly, with the rest going into the gpio tree at some point.
>
> The final patch here obviously needs to wait for all the others
> to get merged first.
This is helpful.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect
From: Stanislav Fomichev @ 2026-06-30 21:18 UTC (permalink / raw)
To: Vladimir Vdovin
Cc: bpf, netdev, ast, daniel, andrii, martin.lau, sdf, hawk,
john.fastabend, kuba, lorenzo
In-Reply-To: <20260630191510.81402-1-deliran@verdict.gg>
On 06/30, Vladimir Vdovin wrote:
> This series lets XDP programs work with the hardware RX checksum verdict:
> read what the NIC concluded about a packet, and carry a "the L4 checksum
> is correct" assertion across a redirect so the stack does not revalidate
> it in software.
>
> When an XDP program redirects a frame to a cpumap (or any other path that
> rebuilds an skb from an xdp_frame via __xdp_build_skb_from_frame()), the
> HW RX checksum status is lost and the stack revalidates the L4 checksum in
> software.
>
> Two kfuncs are added:
>
> - bpf_xdp_metadata_rx_csum(): a device-bound RX-metadata hint, like the
> existing rx_hash / rx_vlan_tag ones. It reports enum xdp_csum_status
> (XDP_CSUM_NONE / XDP_CSUM_VERIFIED) and is implemented for mlx5e, ice
> and veth.
>
> - bpf_xdp_assert_rx_csum(): a generic, non-device-bound kfunc that lets
> the program assert the L4 checksum is correct. It sets a buff flag
> that rides into the xdp_frame, and __xdp_build_skb_from_frame() turns
> it into skb->ip_summed = CHECKSUM_UNNECESSARY. The kernel cannot
> verify the assertion; the program takes responsibility, as it already
> does when rewriting packet contents.
>
> Posted as RFC to get feedback on:
>
> - whether the read hint (bpf_xdp_metadata_rx_csum() and its driver
> support) belongs in this series at all. bpf_xdp_assert_rx_csum() is
> self-contained and already covers the main use case: a program that
> computes or fixes the L4 checksum itself, or trusts the source, and
> wants the rebuilt skb to skip software revalidation. The read hint is
> an optimization for programs that did not touch the payload and only
> want to relay the hardware verdict. These could just as well be two
> independent series (assert-only first);
> - the kfunc naming, bpf_xdp_assert_rx_csum() in particular.
>
> Testing:
>
> - new selftest xdp_cpumap_rx_csum drives a frame through a native-XDP
> veth into a cpumap redirect and checks, via fexit on
> __xdp_build_skb_from_frame(), that the rebuilt skb is
> CHECKSUM_UNNECESSARY iff the program called bpf_xdp_assert_rx_csum();
> - xdp_metadata calls bpf_xdp_metadata_rx_csum() over veth and checks both
> verdicts: XDP_CSUM_NONE for an AF_XDP-injected frame and
> XDP_CSUM_VERIFIED for one sent through the stack.
This was posted somewhat recently from Lorenzo (and had a fair bit of
discussion), but there haven't been a follow up:
https://lore.kernel.org/bpf/20260217-bpf-xdp-meta-rxcksum-v3-0-30024c50ba71@kernel.org/
^ permalink raw reply
* [PATCH net] mac802154: wait for RCU readers when removing interfaces
From: Yousef Alhouseen @ 2026-06-30 21:18 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Marcel Holtmann, linux-wpan, netdev, linux-kernel,
stable, syzbot+36256deb69a588e9290e, Yousef Alhouseen
Queue wake, stop, and disable paths walk local->interfaces under RCU.
The bulk hardware teardown path removes entries with list_del() and
immediately unregisters their netdevices, so an asynchronous transmit
completion can follow a poisoned list node in ieee802154_wake_queue().
Match ieee802154_if_remove(): use list_del_rcu() and wait for existing
readers before unregistering each interface.
Fixes: 592dfbfc72f5 ("mac820154: move interface unregistration into iface")
Reported-by: syzbot+36256deb69a588e9290e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=36256deb69a588e9290e
Cc: stable@vger.kernel.org
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
net/mac802154/iface.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index 000be60d9580..73d82a015184 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -703,7 +703,8 @@ void ieee802154_remove_interfaces(struct ieee802154_local *local)
mutex_lock(&local->iflist_mtx);
list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
- list_del(&sdata->list);
+ list_del_rcu(&sdata->list);
+ synchronize_rcu();
unregister_netdevice(sdata->dev);
}
--
2.55.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox