* Re: [PATCH ethtool-next 0/5] ethtool: Add 'pages on|off' option for module EEROM hex dump
From: Michal Kubecek @ 2026-05-07 12:07 UTC (permalink / raw)
To: Danielle Ratson; +Cc: netdev, idosch, petrm
In-Reply-To: <20260507114721.3409128-1-danieller@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]
On Thu, May 07, 2026 at 02:47:16PM GMT, Danielle Ratson wrote:
> The existing 'ethtool -m' command can dump module EEPROM data either as
> a parsed pretty-print or as a raw/hex dump. The pretty-printer reads
> multiple pages per module type, but decodes only specific fields from them.
>
> In practice, both outputs are often needed together for offline debugging:
> the pretty-print to identify the module type and decoded fields, and the
> hex dump for fields the pretty-printer does not decode. However, there is
> no single command that provides the raw hex dump of all relevant pages,
> organized by page boundary. This is especially problematic for CMIS
> transceivers where the existing hex dump does not provide Upper Pages
> beyond Page 02h, let alone banked pages.
>
> This series adds 'pages on|off' sub-option to 'hex on|off' for
> 'ethtool -m':
> $ ethtool -m hex on pages on
>
> That produces a hex dump organized by page, matching exactly the pages read
> by the pretty-printer for each module type.
Do we need the "pages on|off" switch? Is there a reason not to show the
full dump always (whenever possible) but only when requested explicitly?
Michal
> Each page is preceded by a header identifying the page number and, for
> banked modules, the bank number. For SFP, where the two memory regions
> are separate I2C addresses rather than pages, the header shows the I2C
> address instead.
>
> Output example (values zeroed to omit vendor-specific identifiers):
>
> $ ethtool -m swp61 hex on pages on
> Page: 0x0
>
> Offset Values
> ------ ------
> 0x0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> Page: 0x0
>
> Offset Values
> ------ ------
> 0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] net: phy: air_phy_lib: Factorize BuckPBus register accessors
From: Louis-Alexis Eyraud @ 2026-05-07 12:11 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <3bd7803d-4c4a-4f61-9434-a6bf25627b58@lunn.ch>
Hi Andrew,
On Thu, 2026-03-26 at 13:30 +0100, Andrew Lunn wrote:
> > @@ -480,8 +287,8 @@ static int en8811h_wait_mcu_ready(struct
> > phy_device *phydev)
> > {
> > int ret, reg_value;
> >
> > - ret = air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
> > - EN8811H_FW_CTRL_1_FINISH);
> > + ret = air_phy_buckpbus_reg_write(phydev,
> > EN8811H_FW_CTRL_1,
> > +
> > EN8811H_FW_CTRL_1_FINISH);
>
> Is a rename required? Is the namespace air_buckpbus_ used somewhere
> else?
>
> Andrew
Sorry for the delay.
The air_buckpbus_ namespace is only used in the air_en8811h driver.
It seemed better to me that in the new air_phy_lib, all functions (the
buckpbus accessors and air_phy_read/write_page functions) started with
the same prefix. That is the reason I renamed them, even if not
required.
As an alternative, to avoid renaming those buckpbus function calls on
air_en8811h driver and reduce this patch changes, I can add macros at
the beginning of the file such as:
```
#define air_buckpbus_reg_write(_phydev, _pbus_address, _pbus_data) \
air_phy_buckpbus_reg_write(_phydev, _pbus_address, _pbus_data)
```
Would it be okay?
Best regards,
Louis-Alexis
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: lan966x: Accept standard ethernet prefixes
From: Herve Codina @ 2026-05-07 12:13 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Walleij, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski, Conor Dooley,
Horatiu Vultur, netdev, devicetree
In-Reply-To: <20260507115935.GA1119810-robh@kernel.org>
Hi Rob, Linus,
On Thu, 7 May 2026 06:59:35 -0500
Rob Herring <robh@kernel.org> wrote:
> On Thu, May 07, 2026 at 01:40:43PM +0200, Herve Codina wrote:
> > Hi Linus,
> >
> > On Thu, 07 May 2026 11:26:01 +0200
> > Linus Walleij <linusw@kernel.org> wrote:
> >
> > > The dsa.yaml and ethernet-switch.yaml bindings recommend
> > > prefixing ethernet switches and ports with "ethernet-" so
> > > make the LAN966x do the same.
> > >
> > > Reported-by: Herve Codina <herve.codina@bootlin.com>
> > > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > > ---
> > > .../devicetree/bindings/net/microchip,lan966x-switch.yaml | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
> > > index 306ef9ecf2b9..0f0f35865ef4 100644
> > > --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
> > > +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
> > > @@ -17,7 +17,7 @@ description: |
> > >
> > > properties:
> > > $nodename:
> > > - pattern: "^switch@[0-9a-f]+$"
> > > + pattern: "^(ethernet-)?switch@[0-9a-f]+$"
> > >
> > > compatible:
> > > const: microchip,lan966x-switch
> > > @@ -70,7 +70,7 @@ properties:
> > > additionalProperties: false
> > >
> > > patternProperties:
> > > - "^port@[0-9a-f]+$":
> > > + "^(ethernet-)?port@[0-9a-f]+$":
> > > type: object
> > >
> > > $ref: /schemas/net/ethernet-controller.yaml#
> > > @@ -138,7 +138,7 @@ additionalProperties: false
> > > examples:
> > > - |
> > > #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > - switch: switch@e0000000 {
> > > + switch: ethernet-switch@e0000000 {
> > > compatible = "microchip,lan966x-switch";
> > > reg = <0xe0000000 0x0100000>,
> > > <0xe2000000 0x0800000>;
> > > @@ -151,14 +151,14 @@ examples:
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > - port0: port@0 {
> > > + port0: ethernet-port@0 {
> > > reg = <0>;
> > > phy-handle = <&phy0>;
> > > phys = <&serdes 0 0>;
> > > phy-mode = "gmii";
> > > };
> > >
> > > - port1: port@1 {
> > > + port1: ethernet-port@1 {
> > > reg = <1>;
> > > sfp = <&sfp_eth1>;
> > > managed = "in-band-status";
> > >
> > > ---
> > > base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> > > change-id: 20260507-lan966-binding-0df62a018509
> > >
> > > Best regards,
> > > --
> > > Linus Walleij <linusw@kernel.org>
> > >
> >
> > With those changes, dtb_check will not be happy when following dtsi/dts are
> > involved:
> > - arch/arm/boot/dts/microchip/lan966x.dtsi
> > - arch/arm/boot/dts/microchip/lan966x-kontron-kswitch-d10-mmt.dtsi
> > - arch/arm/boot/dts/microchip/lan966x-pcb8290.dts
> > - arch/arm/boot/dts/microchip/lan966x-kontron-kswitch-d10-mmt-6g-2gs.dts
> > - arch/arm/boot/dts/microchip/lan966x-kontron-kswitch-d10-mmt-8g.dts
>
> How so? the added prefix is optional.
Oups, I've missed that. My bad.
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Sorry for the noise.
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH net-next 09/12] gpio: tc956x: add TC956x/QPS615 support
From: Linus Walleij @ 2026-05-07 12:15 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
andersson, konradybcio, robh, krzk+dt, conor+dt, brgl, arnd,
gregkh, daniel, wens, netdev, bpf, devicetree, linux-gpio,
linux-arm-kernel
In-Reply-To: <20260501155421.3329862-10-elder@riscstar.com>
Hi Alex,
thanks for your patch!
On Fri, May 1, 2026 at 5:55 PM Alex Elder <elder@riscstar.com> wrote:
> Toshiba TC956x is an Ethernet-AVB/TSN bridge and is essentially
> a small and highly-specialized SoC. TC956x includes a GPIO block that
> can be accessed, alongside several other peripherals, via two PCIe
> endpoint functions. The PCIe function driver creates an auxiliary
> device for the GPIO block, and that device gets bound to this auxiliary
> device driver.
>
> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
(...)
> +config GPIO_TC956X
> + tristate "Toshiba TC956X GPIO support"
> + depends on TOSHIBA_TC956X_PCI
> + default m if TOSHIBA_TC956X_PCI
I think this driver can
select GPIO_REGMAP
> +#include <linux/auxiliary_bus.h>
> +#include <linux/dev_printk.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
#include <linux/gpio/regmap.h>
> +#define TC956X_GPIO_COUNT 37 /* Number of GPIOs (20-21 reserved) */
I would just do 64 and flag > 37 as invalid.
> +/*
> + * struct tc956x_gpio - Information related to the embedded GPIO controller
> + * @chip: GPIO chip structure
> + * @regmap: MMIO register map for SFR GPIO region access
> + * @input_only: Bitmap indicating which GPIOs are input-only
> + */
> +struct tc956x_gpio {
> + struct gpio_chip chip;
> + struct regmap *regmap;
> + DECLARE_BITMAP(input_only, TC956X_GPIO_COUNT);
> +static int tc956x_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
> +static int tc956x_gpio_direction_input(struct gpio_chip *gc,
> + unsigned int offset)
> +static int tc956x_gpio_direction_output(struct gpio_chip *gc,
> + unsigned int offset, int value)
> +static int tc956x_gpio_get(struct gpio_chip *gc, unsigned int offset)
> +static int tc956x_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
REGMAP_GPIO can handle all of this for you with the right
parameterization, study the drivers using this already such as
those that appear when you type
git grep 'gpio\/regmap\.h'
> +static int tc956x_gpio_init_valid_mask(struct gpio_chip *gc,
> + unsigned long *valid_mask,
> + unsigned int ngpios)
> +{
> + /*
> + * GPIOs 2 and 3 are used by the PCI power control driver, and
> + * we don't allow them to be used. GPIOs 20 and 21 are reserved
> + * (and not usable).
> + */
> + bitmap_fill(valid_mask, ngpios);
> + bitmap_clear(valid_mask, 2, 2);
> + bitmap_clear(valid_mask, 20, 2);
> +
> + return 0;
> +}
That's good use of this facility.
I would say the chip has 64 lines and just
bitmap_clear(valid_mask, 37, 64 - 37);
but that's your pick. This probably works too.
> + /* Mark GPIOs 22, 23, 24, 27, 28, 31, and 34 as input only */
> + bitmap_set(gpio->input_only, 22, 3);
> + bitmap_set(gpio->input_only, 27, 2);
> + set_bit(31, gpio->input_only);
> + set_bit(34, gpio->input_only);
regmap-gpio can't currently handle selective input-only or
output-only lines, but we can
very easily make it.
So I sent a patch for that (now in your inbox).
Check if this fixed_direction_sparse bitmap will do the trick
for you and provide Tested-by if it does, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH iwl-next v4 0/3] igc: add support for forcing link speed without autonegotiation
From: Andrew Lunn @ 2026-05-07 12:15 UTC (permalink / raw)
To: Abdul Rahim, Faizal
Cc: David Laight, KhaiWenTan, anthony.l.nguyen, andrew+netdev, davem,
edumazet, kuba, pabeni, intel-wired-lan, netdev, linux-kernel,
faizal.abdul.rahim, hong.aun.looi, khai.wen.tan,
hector.blanco.alcaine
In-Reply-To: <78e48cc4-759f-46e1-83c7-1c9442308ae3@linux.intel.com>
> I agree that for normal Ethernet use, auto-negotiation on both link
> partners is safer and avoids the issues you mentioned.
>
> The reason for this patch is the more specific PROFINET Fast Start Up
> (FSU) use case. For FSU, the requirement is different from normal Ethernet
> use. It is intended for deterministic startup, for example in industrial
> robot/tool-change applications.
>
> One of the startup optimizations is to use "fixed transmission parameters"
> instead of automatic detection in the profinet specification:
> https://us.profinet.com/profinet_tech/fast-start-up/
Automotive also have similar requirements. For them, Autoneg is slow,
takes around 1 second, where as a fixed link is operative very
fast. There are even some automotive ethernet devices which don't even
support autoneg.
So this use case makes sense to me, for embedded systems. If the
hardware can do it, any most PHYs can, i see no reason not to support
it. And anything using phylib gets it for free.
Andrew
^ permalink raw reply
* [net-next v3 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Minda Chen @ 2026-05-07 9:41 UTC (permalink / raw)
To: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260507094115.8355-1-minda.chen@starfivetech.com>
Add default disable split header flag in all the starfive
soc.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
index bd86a39b79f0..935c4fc4c29f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-starfive.c
@@ -147,7 +147,7 @@ static int starfive_dwmac_probe(struct platform_device *pdev)
return err;
}
- plat_dat->flags |= STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP;
+ plat_dat->flags |= (STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP | STMMAC_FLAG_SPH_DISABLE);
plat_dat->dma_cfg->dche = true;
return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 09/12] gpio: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-05-07 12:20 UTC (permalink / raw)
To: Linus Walleij
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
andersson, konradybcio, robh, krzk+dt, conor+dt, brgl, arnd,
gregkh, daniel, wens, netdev, bpf, devicetree, linux-gpio,
linux-arm-kernel
In-Reply-To: <CAD++jLkm4qn9hxQ9HjjnTWjvAiS+A+x1ATy7wamnm_YSP_qPEg@mail.gmail.com>
On 5/7/26 7:15 AM, Linus Walleij wrote:
> Hi Alex,
>
> thanks for your patch!
Thank you for your excellent feedback. I will plan to use
regmap-gpio (already suggested strongly by Andrew Lunn) and
that will be included in the next version of the series.
Once I've done this and tried your other patch I'll provide
a Tested-by for it.
-Alex
>
> On Fri, May 1, 2026 at 5:55 PM Alex Elder <elder@riscstar.com> wrote:
>
>> Toshiba TC956x is an Ethernet-AVB/TSN bridge and is essentially
>> a small and highly-specialized SoC. TC956x includes a GPIO block that
>> can be accessed, alongside several other peripherals, via two PCIe
>> endpoint functions. The PCIe function driver creates an auxiliary
>> device for the GPIO block, and that device gets bound to this auxiliary
>> device driver.
>>
>> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
> (...)
>
>> +config GPIO_TC956X
>> + tristate "Toshiba TC956X GPIO support"
>> + depends on TOSHIBA_TC956X_PCI
>> + default m if TOSHIBA_TC956X_PCI
>
> I think this driver can
>
> select GPIO_REGMAP
>
>> +#include <linux/auxiliary_bus.h>
>> +#include <linux/dev_printk.h>
>> +#include <linux/gpio/driver.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>
> #include <linux/gpio/regmap.h>
>
>> +#define TC956X_GPIO_COUNT 37 /* Number of GPIOs (20-21 reserved) */
>
> I would just do 64 and flag > 37 as invalid.
>
>> +/*
>> + * struct tc956x_gpio - Information related to the embedded GPIO controller
>> + * @chip: GPIO chip structure
>> + * @regmap: MMIO register map for SFR GPIO region access
>> + * @input_only: Bitmap indicating which GPIOs are input-only
>> + */
>> +struct tc956x_gpio {
>> + struct gpio_chip chip;
>> + struct regmap *regmap;
>> + DECLARE_BITMAP(input_only, TC956X_GPIO_COUNT);
>
>> +static int tc956x_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
>> +static int tc956x_gpio_direction_input(struct gpio_chip *gc,
>> + unsigned int offset)
>> +static int tc956x_gpio_direction_output(struct gpio_chip *gc,
>> + unsigned int offset, int value)
>> +static int tc956x_gpio_get(struct gpio_chip *gc, unsigned int offset)
>> +static int tc956x_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
>
> REGMAP_GPIO can handle all of this for you with the right
> parameterization, study the drivers using this already such as
> those that appear when you type
> git grep 'gpio\/regmap\.h'
>
>
>> +static int tc956x_gpio_init_valid_mask(struct gpio_chip *gc,
>> + unsigned long *valid_mask,
>> + unsigned int ngpios)
>> +{
>> + /*
>> + * GPIOs 2 and 3 are used by the PCI power control driver, and
>> + * we don't allow them to be used. GPIOs 20 and 21 are reserved
>> + * (and not usable).
>> + */
>> + bitmap_fill(valid_mask, ngpios);
>> + bitmap_clear(valid_mask, 2, 2);
>> + bitmap_clear(valid_mask, 20, 2);
>> +
>> + return 0;
>> +}
>
> That's good use of this facility.
>
> I would say the chip has 64 lines and just
> bitmap_clear(valid_mask, 37, 64 - 37);
> but that's your pick. This probably works too.
>
>> + /* Mark GPIOs 22, 23, 24, 27, 28, 31, and 34 as input only */
>> + bitmap_set(gpio->input_only, 22, 3);
>> + bitmap_set(gpio->input_only, 27, 2);
>> + set_bit(31, gpio->input_only);
>> + set_bit(34, gpio->input_only);
>
> regmap-gpio can't currently handle selective input-only or
> output-only lines, but we can
> very easily make it.
>
> So I sent a patch for that (now in your inbox).
>
> Check if this fixed_direction_sparse bitmap will do the trick
> for you and provide Tested-by if it does, thanks!
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH bpf-next v4 05/12] bpf: Refactor object relationship tracking and fix dynptr UAF bug
From: Amery Hung @ 2026-05-07 12:20 UTC (permalink / raw)
To: bot+bpf-ci
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team, ast, yonghong.song,
clm, ihor.solodrai
In-Reply-To: <755de35ed30756cc0f8c3f1dae3cf6d6b82be6f066353b8421d38f9605f64ff1@mail.kernel.org>
On Wed, May 6, 2026 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > index f330e9cf297e..51d5f5dd6e5b 100644
> > --- a/include/linux/bpf_verifier.h
> > +++ b/include/linux/bpf_verifier.h
>
> [ ... ]
>
> > @@ -1381,6 +1394,7 @@ struct bpf_dynptr_desc {
> > enum bpf_dynptr_type type;
> > u32 id;
> > u32 ref_obj_id;
> > + u32 parent_id;
> > };
>
> Eduard Zingerman raised a suggestion in v3 about adding documentation
> comments to struct bpf_dynptr_desc. The structure still lacks comments
> explaining when the id, ref_obj_id, and parent_id fields are populated.
> Would it help readers to document when these fields are set?
>
> >
> > struct bpf_kfunc_call_arg_meta {
> > @@ -1392,6 +1406,7 @@ struct bpf_kfunc_call_arg_meta {
> > const char *func_name;
> > /* Out parameters */
> > u32 ref_obj_id;
> > + u32 id;
> > u8 release_regno;
> > bool r0_rdonly;
> > u32 ret_btf_id;
>
> Eduard Zingerman suggested in v3 adding a comment for the new id field
> in struct bpf_kfunc_call_arg_meta. The field remains undocumented. Would
> a comment clarifying its purpose improve code readability?
The readability should be improved in patch 7 where ref_obj_id and id
are moved into ref_obj_desc.
For the meaning of id and ref_obj_id, we should keep it in where they
are defined: bpf_verifier.h
>
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25442456702
^ permalink raw reply
* Re: [PATCH bpf-next v4 02/12] bpf: Unify dynptr handling in the verifier
From: Amery Hung @ 2026-05-07 12:22 UTC (permalink / raw)
To: bot+bpf-ci
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team, ast, yonghong.song,
clm, ihor.solodrai
In-Reply-To: <6083c00dc3cc6e72f6a4d0d2ad6632f0950bf12b5c09e873d614128db8758cd9@mail.kernel.org>
On Wed, May 6, 2026 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > index 976e2b2f40e8..f330e9cf297e 100644
> > --- a/include/linux/bpf_verifier.h
> > +++ b/include/linux/bpf_verifier.h
> > @@ -1376,6 +1376,13 @@ struct bpf_map_desc {
> > int uid;
> > };
> >
> > +/* The last initialized dynptr; Populated by process_dynptr_func() */
> > +struct bpf_dynptr_desc {
> > + enum bpf_dynptr_type type;
> > + u32 id;
> > + u32 ref_obj_id;
> > +};
> > +
>
> A review comment from Mykyta Yatsenko requested that a comment be added
> to the ref_obj_id field explaining what it's for:
>
> https://lore.kernel.org/bpf/87ikb2tkta.fsf@gmail.com/
>
> The author mentioned in v3 that comments for id, ref_obj_id, and parent_id
> would be added in a later refactor patch. However, should this struct have
> inline documentation now for clarity, particularly for the ref_obj_id field?
For the meaning of id, ref_obj_id and parent_id, keep the
documentation in where they are defined: bpf_verifier.h
>
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25442456702
^ permalink raw reply
* Re: [PATCH ethtool-next 0/5] ethtool: Add 'pages on|off' option for module EEROM hex dump
From: Andrew Lunn @ 2026-05-07 12:23 UTC (permalink / raw)
To: Danielle Ratson; +Cc: netdev, mkubecek, idosch, petrm
In-Reply-To: <20260507114721.3409128-1-danieller@nvidia.com>
> In practice, both outputs are often needed together for offline debugging:
> Output example (values zeroed to omit vendor-specific identifiers):
>
> $ ethtool -m swp61 hex on pages on
> Page: 0x0
>
> Offset Values
> ------ ------
> 0x0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> Page: 0x0
Maybe also add JSON? That would make machine parsing of this easier.
Andrew
^ permalink raw reply
* Re: [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description
From: Andrew Lunn @ 2026-05-07 12:29 UTC (permalink / raw)
To: lizhi2
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, netdev, devicetree, linux-kernel, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, linux-stm32,
linux-arm-kernel, ningyu, linmin, pinkesh.vaghela, pritesh.patel,
weishangjuan
In-Reply-To: <20260507083136.175-1-lizhi2@eswincomputing.com>
> ethernet@50400000 {
> compatible = "eswin,eic7700-qos-eth", "snps,dwmac-5.20";
> reg = <0x50400000 0x10000>;
> - clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
> - <&d0_clock 193>;
> - clock-names = "axi", "cfg", "stmmaceth", "tx";
> interrupt-parent = <&plic>;
> interrupts = <61>;
> interrupt-names = "macirq";
> - phy-mode = "rgmii-id";
> - phy-handle = <&phy0>;
> + clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
> + <&d0_clock 193>;
> + clock-names = "axi", "cfg", "stmmaceth", "tx";
Please don't move the clocks around, since they have nothing to do
with RGMII delays.
> resets = <&reset 95>;
> reset-names = "stmmaceth";
> - rx-internal-delay-ps = <200>;
> - tx-internal-delay-ps = <200>;
> - eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>;
> - snps,axi-config = <&stmmac_axi_setup>;
> + eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118 0x114 0x11c>;
> + phy-handle = <&phy0>;
> + phy-mode = "rgmii-id";
> snps,aal;
> snps,fixed-burst;
> snps,tso;
> - stmmac_axi_setup: stmmac-axi-config {
> + snps,axi-config = <&stmmac_axi_setup_gmac0>;
> +
> + stmmac_axi_setup_gmac0: stmmac-axi-config {
And what do these changes have to do with RGMII delays?
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v3 1/4] net: rnpgbe: Add interrupt handling
From: Vadim Fedorenko @ 2026-05-07 12:30 UTC (permalink / raw)
To: Dong Yibo, andrew+netdev, davem, edumazet, kuba, pabeni,
danishanwar, horms
Cc: linux-kernel, netdev, yaojun
In-Reply-To: <20260507081539.171844-2-dong100@mucse.com>
On 07/05/2026 09:15, Dong Yibo wrote:
> Add comprehensive interrupt handling for the RNPGBE driver:
> - Implement msi-x/msi interrupt configuration and management
> - Create library functions for interrupt registration and cleanup
>
> This infrastructure enables proper interrupt handling for the
> RNPGBE driver.
>
[...]
> +/**
> + * rnpgbe_set_interrupt_capability - Set MSI-X or MSI if supported
> + * @mucse: pointer to private structure
> + *
> + * Attempt to configure the interrupts using the best available
> + * capabilities of the hardware.
> + *
> + * @return: 0 on success, negative on failure
> + **/
> +static int rnpgbe_set_interrupt_capability(struct mucse *mucse)
> +{
> + int v_budget;
> +
> + v_budget = min_t(int, mucse->num_tx_queues, mucse->num_rx_queues);
> + v_budget = min_t(int, v_budget, MAX_Q_VECTORS);
these 2 lines can be simplified to
min3(mucse->num_tx_queues, mucse->num_rx_queues, MAX_Q_VECTORS);
> + v_budget = min_t(int, v_budget, num_online_cpus());
> + /* add one vector for mbx */> + v_budget += 1;
> + v_budget = pci_alloc_irq_vectors(mucse->pdev, 1, v_budget,
> + PCI_IRQ_MSI | PCI_IRQ_MSIX);
> + if (v_budget < 0)
> + return v_budget;
> +
> + if (mucse->pdev->msix_enabled) {
> + /* q_vector not include mbx */
> + if (v_budget > 1) {
> + mucse->flags |= M_FLAG_MSIX_EN;
> + mucse->num_q_vectors = v_budget - 1;
> + } else {
> + mucse->flags |= M_FLAG_MSIX_SINGLE_EN;
> + mucse->num_q_vectors = 1;
> + }
> + } else {
> + /* msi use only 1 irq */
> + mucse->num_q_vectors = 1;
> + mucse->flags |= M_FLAG_MSI_EN;
> + }
How will it work in case it's only 1 vector allocated? AFAIU, you need
at least 2 irq vectors - 1 for queue processing, another one for mbx.
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [net-next v3 0/5] Add StarFive jhb100 soc SGMII GMAC support
From: Andrew Lunn @ 2026-05-07 12:31 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260507094115.8355-1-minda.chen@starfivetech.com>
On Thu, May 07, 2026 at 05:41:10PM +0800, Minda Chen wrote:
> jhb100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
> Managent Controller). Similar with Aspeed 27x0.
>
> The jhb100 minimal system upstream is in progress:
> https://patchwork.kernel.org/project/linux-riscv/cover/20260403054945.467700-1-changhuang.liang@starfivetech.com/
>
> jhb100 GMAC still using designware GMAC core like JH7100 and JH7110,
> and contains 2 SGMII interfaces, 1 RGMII/RMII interface, 1 RMII
> interface. In JH7100/JH7110 dwmac-starfive.c have supported RGMII/RMII
> interface. So require to add SGMII support to dwmac-starfive.c for JHB100.
>
> SGMII serdes PHY has been integrated in JHB100 and do not have driver
> setting.
>
> In JHB100 EVB board, SGMII connect with motorcomm YT8531s external PHY
> and support RJ45 ethernet port.
>
> The patch base in 7.1-rc2
For networking, please base on net-next/main.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
^ permalink raw reply
* Re: [net-next v3 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove jh8100
From: Andrew Lunn @ 2026-05-07 12:31 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260507094115.8355-2-minda.chen@starfivetech.com>
On Thu, May 07, 2026 at 05:41:11PM +0800, Minda Chen wrote:
> Remove jh8100 dt-bindings because do not support it now.
> StarFive have stopped jh8100 developing and will not release
> it outside.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* RE: [PATCH ethtool-next 0/5] ethtool: Add 'pages on|off' option for module EEROM hex dump
From: Danielle Ratson @ 2026-05-07 12:37 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev@vger.kernel.org, Ido Schimmel, Petr Machata
In-Reply-To: <4chkrvenxrbc2tylrbob6vdo3uyjzbwbhbup25yvnohrccvotv@fd7rqasq4btv>
> -----Original Message-----
> From: Michal Kubecek <mkubecek@suse.cz>
> Sent: Thursday, 7 May 2026 15:08
> To: Danielle Ratson <danieller@nvidia.com>
> Cc: netdev@vger.kernel.org; Ido Schimmel <idosch@nvidia.com>; Petr
> Machata <petrm@nvidia.com>
> Subject: Re: [PATCH ethtool-next 0/5] ethtool: Add 'pages on|off' option for
> module EEROM hex dump
>
> On Thu, May 07, 2026 at 02:47:16PM GMT, Danielle Ratson wrote:
> > The existing 'ethtool -m' command can dump module EEPROM data either
> > as a parsed pretty-print or as a raw/hex dump. The pretty-printer
> > reads multiple pages per module type, but decodes only specific fields from
> them.
> >
> > In practice, both outputs are often needed together for offline debugging:
> > the pretty-print to identify the module type and decoded fields, and
> > the hex dump for fields the pretty-printer does not decode. However,
> > there is no single command that provides the raw hex dump of all
> > relevant pages, organized by page boundary. This is especially
> > problematic for CMIS transceivers where the existing hex dump does not
> > provide Upper Pages beyond Page 02h, let alone banked pages.
> >
> > This series adds 'pages on|off' sub-option to 'hex on|off' for
> > 'ethtool -m':
> > $ ethtool -m hex on pages on
> >
> > That produces a hex dump organized by page, matching exactly the pages
> > read by the pretty-printer for each module type.
>
> Do we need the "pages on|off" switch? Is there a reason not to show the full
> dump always (whenever possible) but only when requested explicitly?
>
> Michal
Thanks for the feedback.
The reason for keeping the switch is backward compatibility: today's ethtool -m hex on produces a single flat hex dump, while the page-organized output has a different shape - per-page headers, blank lines and repeated column headers interleaved between hex rows. Scripts that parse today's output could break.
For comparison, today's hex on looks like (values zeroed):
$ ethtool -m swp61 hex on
Offset Values
------ ------
0x0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
vs. the page-organized output in the cover letter, where each page is preceded by a Page: header and a fresh Offset/------ block.
Since the format changes shape and not just size, we kept it opt-in via pages on so existing consumers are unaffected.
Are you OK with this even so it might break some existing usage?
Thanks,
Danielle
>
> > Each page is preceded by a header identifying the page number and, for
> > banked modules, the bank number. For SFP, where the two memory regions
> > are separate I2C addresses rather than pages, the header shows the I2C
> > address instead.
> >
> > Output example (values zeroed to omit vendor-specific identifiers):
> >
> > $ ethtool -m swp61 hex on pages on
> > Page: 0x0
> >
> > Offset Values
> > ------ ------
> > 0x0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >
> > Page: 0x0
> >
> > Offset Values
> > ------ ------
> > 0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^ permalink raw reply
* Re: [PATCH bpf-next v4 03/12] bpf: Assign reg->id when getting referenced kptr from ctx
From: Amery Hung @ 2026-05-07 12:38 UTC (permalink / raw)
To: bot+bpf-ci
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team, ast, yonghong.song,
clm, ihor.solodrai
In-Reply-To: <c50e87ba73094da8cf153aa71d110868fe0e0e27bea866e294af7647712c9a6a@mail.kernel.org>
On Wed, May 6, 2026 at 4:27 PM <bot+bpf-ci@kernel.org> wrote:
>
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -6057,8 +6057,6 @@ struct bpf_insn_access_aux info = {
> > } else {
> > mark_reg_known_zero(env, regs,
> > value_regno);
> > - if (type_may_be_null(info.reg_type))
> > - regs[value_regno].id = ++env->id_gen;
> > /* A load of ctx field could have different
> > * actual load size with the one encoded in the
> > * insn. When the dst is PTR, it is for sure not
> > @@ -6068,8 +6066,11 @@ struct bpf_insn_access_aux info = {
> > if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> > regs[value_regno].btf = info.btf;
> > regs[value_regno].btf_id = info.btf_id;
> > + regs[value_regno].id = info.ref_obj_id;
> ^^^^
>
> Does this introduce a bug when reading the same nullable context field
> multiple times?
>
> The new code sets reg->id = info.ref_obj_id, where ref_obj_id comes from
> ctx_arg_info->ref_obj_id. The ctx_arg_info structure is initialized once
> during program type setup in check_attach_btf_id(), making ref_obj_id a
> static value per context field, not per read.
>
> When a BPF program reads the same nullable context field into different
> registers, they would share the same ID:
>
> r1 = ctx->nullable_kptr; // r1->id = ref_obj_id = 5
> r2 = ctx->nullable_kptr; // r2->id = ref_obj_id = 5 (SAME!)
> if (r1 != NULL) {
> // mark_ptr_or_null_regs(id=5) marks ALL registers with id==5
> // Both r1 AND r2 are now considered safe
> use(r2); // BUG: r2 was never checked but verifier allows use
> }
>
> The mark_ptr_or_null_reg() function uses reg->id to identify which
> registers should be updated together after a NULL check. With shared IDs,
> independent reads are incorrectly treated as aliases.
I don't think this is a bug. They are indeed aliases. The referenced
kptr acquired from struct_ops argument, if valid, should always have
the same ref_obj_id (also id) because they point to the same kernel
object
>
> The old code generated a unique ID via ++env->id_gen for each nullable
> read, ensuring proper NULL-check tracking.
>
> > regs[value_regno].ref_obj_id = info.ref_obj_id;
> > }
> > + if (type_may_be_null(info.reg_type) && !regs[value_regno].id)
> > + regs[value_regno].id = ++env->id_gen;
>
> Would this fallback path prevent fresh ID generation when id was already
> set to ref_obj_id? The condition '!regs[value_regno].id' is now false for
> nullable PTR_TO_BTF_ID pointers, so each read gets the same static ID
> instead of a unique one.
Yes. It is intentional. This mirror referenced object obtained through
KF_ACQUIRE kfunc, where id == ref_obj.
>
> Eduard Zingerman's review comment from v3 suggested that the commit message
> should mention that this patch is mandatory for proper invalidation
> propagation in later patches. He noted that without the line
> 'regs[value_regno].id = info.ref_obj_id;', the test
> 'bpf_qdisc_fail__invalid_dynptr_cross_frame.c:invalid_dynptr_cross_frame'
> fails because the .id link is needed to propagate invalidation triggered by
> 'free_skb(skb);' to 'hdr'. The current commit message mentions consistency
> and parent_id tracking but does not explicitly mention the invalidation
> propagation aspect.
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25442456702
^ permalink raw reply
* Re: [net-next v3 4/5] net: stmmac: starfive: Add jhb100 SGMII interface
From: Andrew Lunn @ 2026-05-07 12:41 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260507094115.8355-5-minda.chen@starfivetech.com>
> +static int stmmac_starfive_sgmii_set_clk_rate(void *bsp_priv, struct clk *clk_tx_i,
> + phy_interface_t __maybe_unused interface,
> + int speed)
> +{
> + struct starfive_dwmac *dwmac = (void *)bsp_priv;
Why (void *) when it is already a void *?
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [net-next v3 5/5] net: stmmac: starfive: Add STMMAC_FLAG_SPH_DISABLE flag
From: Andrew Lunn @ 2026-05-07 12:42 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260507094115.8355-6-minda.chen@starfivetech.com>
On Thu, May 07, 2026 at 05:41:15PM +0800, Minda Chen wrote:
> Add default disable split header flag in all the starfive
> soc.
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v5 net-next 11/15] net: dsa: netc: add phylink MAC operations
From: Maxime Chevallier @ 2026-05-07 12:44 UTC (permalink / raw)
To: Wei Fang, claudiu.manoil, vladimir.oltean, xiaoning.wang,
andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, f.fainelli, frank.li, chleroy, horms, linux
Cc: netdev, linux-kernel, devicetree, linuxppc-dev, linux-arm-kernel,
imx
In-Reply-To: <20260430024945.3413973-12-wei.fang@nxp.com>
Hi,
On 30/04/2026 04:49, Wei Fang wrote:
> Different versions of NETC switches have different numbers of ports and
> MAC capabilities. Add .phylink_get_caps() to struct netc_switch_info,
> allowing each NETC switch version to implement its own callback for
> obtaining MAC capabilities.
>
> Implement the phylink_mac_ops callbacks: .mac_config(), .mac_link_up(),
> and .mac_link_down(). Note that flow-control configuration is not yet
> supported in .mac_link_up(), but will be implemented in a subsequent
> patch.
>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
The phylink part looks good to me,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
> ---
> drivers/net/dsa/netc/netc_main.c | 243 ++++++++++++++++++++++++++
> drivers/net/dsa/netc/netc_platform.c | 38 ++++
> drivers/net/dsa/netc/netc_switch.h | 4 +
> drivers/net/dsa/netc/netc_switch_hw.h | 26 +++
> 4 files changed, 311 insertions(+)
>
> diff --git a/drivers/net/dsa/netc/netc_main.c b/drivers/net/dsa/netc/netc_main.c
> index 90a2d8cfd3d2..edf50cb32cb6 100644
> --- a/drivers/net/dsa/netc/netc_main.c
> +++ b/drivers/net/dsa/netc/netc_main.c
> @@ -44,6 +44,26 @@ static void netc_mac_port_wr(struct netc_port *np, u32 reg, u32 val)
> netc_port_wr(np, reg + NETC_PMAC_OFFSET, val);
> }
>
> +static void netc_mac_port_rmw(struct netc_port *np, u32 reg,
> + u32 mask, u32 val)
> +{
> + u32 old, new;
> +
> + if (is_netc_pseudo_port(np))
> + return;
> +
> + WARN_ON((mask | val) != mask);
> +
> + old = netc_port_rd(np, reg);
> + new = (old & ~mask) | val;
> + if (new == old)
> + return;
> +
> + netc_port_wr(np, reg, new);
> + if (np->caps.pmac)
> + netc_port_wr(np, reg + NETC_PMAC_OFFSET, new);
> +}
> +
> static void netc_port_get_capability(struct netc_port *np)
> {
> u32 val;
> @@ -522,10 +542,232 @@ static void netc_switch_get_ip_revision(struct netc_switch *priv)
> priv->revision = FIELD_GET(IPBRR0_IP_REV, val);
> }
>
> +static void netc_phylink_get_caps(struct dsa_switch *ds, int port,
> + struct phylink_config *config)
> +{
> + struct netc_switch *priv = ds->priv;
> +
> + priv->info->phylink_get_caps(port, config);
> +}
> +
> +static void netc_port_set_mac_mode(struct netc_port *np,
> + unsigned int mode,
> + phy_interface_t phy_mode)
> +{
> + u32 mask = PM_IF_MODE_IFMODE | PM_IF_MODE_REVMII;
> + u32 val = 0;
> +
> + switch (phy_mode) {
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + val |= IFMODE_RGMII;
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + val |= IFMODE_RMII;
> + break;
> + case PHY_INTERFACE_MODE_REVMII:
> + val |= PM_IF_MODE_REVMII;
> + fallthrough;
> + case PHY_INTERFACE_MODE_MII:
> + val |= IFMODE_MII;
> + break;
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_2500BASEX:
> + val |= IFMODE_SGMII;
> + break;
> + default:
> + break;
> + }
> +
> + netc_mac_port_rmw(np, NETC_PM_IF_MODE(0), mask, val);
> +}
> +
> +static void netc_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> + struct dsa_port *dp = dsa_phylink_to_port(config);
> +
> + netc_port_set_mac_mode(NETC_PORT(dp->ds, dp->index), mode,
> + state->interface);
> +}
> +
> +static void netc_port_set_speed(struct netc_port *np, int speed)
> +{
> + netc_port_rmw(np, NETC_PCR, PCR_PSPEED, PSPEED_SET_VAL(speed));
> +}
> +
> +static void netc_port_set_rgmii_mac(struct netc_port *np,
> + int speed, int duplex)
> +{
> + u32 mask, val;
> +
> + mask = PM_IF_MODE_SSP | PM_IF_MODE_HD | PM_IF_MODE_M10;
> +
> + switch (speed) {
> + default:
> + case SPEED_1000:
> + val = FIELD_PREP(PM_IF_MODE_SSP, SSP_1G);
> + break;
> + case SPEED_100:
> + val = FIELD_PREP(PM_IF_MODE_SSP, SSP_100M);
> + break;
> + case SPEED_10:
> + val = FIELD_PREP(PM_IF_MODE_SSP, SSP_10M);
> + break;
> + }
> +
> + if (duplex != DUPLEX_FULL)
> + val |= PM_IF_MODE_HD;
> +
> + netc_mac_port_rmw(np, NETC_PM_IF_MODE(0), mask, val);
> +}
> +
> +static void netc_port_set_rmii_mii_mac(struct netc_port *np,
> + int speed, int duplex)
> +{
> + u32 mask, val = 0;
> +
> + mask = PM_IF_MODE_SSP | PM_IF_MODE_HD | PM_IF_MODE_M10;
> +
> + if (speed == SPEED_10)
> + val |= PM_IF_MODE_M10;
> +
> + if (duplex != DUPLEX_FULL)
> + val |= PM_IF_MODE_HD;
> +
> + netc_mac_port_rmw(np, NETC_PM_IF_MODE(0), mask, val);
> +}
> +
> +static void netc_port_mac_rx_enable(struct netc_port *np)
> +{
> + netc_port_rmw(np, NETC_POR, POR_RXDIS, 0);
> + netc_mac_port_rmw(np, NETC_PM_CMD_CFG(0), PM_CMD_CFG_RX_EN,
> + PM_CMD_CFG_RX_EN);
> +}
> +
> +static void netc_port_wait_rx_empty(struct netc_port *np, int mac)
> +{
> + u32 val;
> +
> + /* PM_IEVENT_RX_EMPTY is a read-only bit, it is automatically set by
> + * hardware if RX FIFO is empty and no RX packet receive in process.
> + * And it is automatically cleared if RX FIFO is not empty or RX
> + * packet receive in process.
> + */
> + if (read_poll_timeout(netc_port_rd, val, val & PM_IEVENT_RX_EMPTY,
> + 100, 10000, false, np, NETC_PM_IEVENT(mac)))
> + dev_warn(np->switch_priv->dev,
> + "swp%d MAC%d: RX is not idle\n", np->dp->index, mac);
> +}
> +
> +static void netc_port_mac_rx_graceful_stop(struct netc_port *np)
> +{
> + u32 val;
> +
> + if (is_netc_pseudo_port(np))
> + goto rx_disable;
> +
> + if (np->caps.pmac) {
> + netc_port_rmw(np, NETC_PM_CMD_CFG(1), PM_CMD_CFG_RX_EN, 0);
> + netc_port_wait_rx_empty(np, 1);
> + }
> +
> + netc_port_rmw(np, NETC_PM_CMD_CFG(0), PM_CMD_CFG_RX_EN, 0);
> + netc_port_wait_rx_empty(np, 0);
> +
> + if (read_poll_timeout(netc_port_rd, val, !(val & PSR_RX_BUSY),
> + 100, 10000, false, np, NETC_PSR))
> + dev_warn(np->switch_priv->dev, "swp%d RX is busy\n",
> + np->dp->index);
> +
> +rx_disable:
> + netc_port_rmw(np, NETC_POR, POR_RXDIS, POR_RXDIS);
> +}
> +
> +static void netc_port_mac_tx_enable(struct netc_port *np)
> +{
> + netc_mac_port_rmw(np, NETC_PM_CMD_CFG(0), PM_CMD_CFG_TX_EN,
> + PM_CMD_CFG_TX_EN);
> + netc_port_rmw(np, NETC_POR, POR_TXDIS, 0);
> +}
> +
> +static void netc_port_wait_tx_empty(struct netc_port *np, int mac)
> +{
> + u32 val;
> +
> + /* PM_IEVENT_TX_EMPTY is a read-only bit, it is automatically set by
> + * hardware if TX FIFO is empty. And it is automatically cleared if
> + * TX FIFO is not empty.
> + */
> + if (read_poll_timeout(netc_port_rd, val, val & PM_IEVENT_TX_EMPTY,
> + 100, 10000, false, np, NETC_PM_IEVENT(mac)))
> + dev_warn(np->switch_priv->dev,
> + "swp%d MAC%d: TX FIFO is not empty\n",
> + np->dp->index, mac);
> +}
> +
> +static void netc_port_mac_tx_graceful_stop(struct netc_port *np)
> +{
> + netc_port_rmw(np, NETC_POR, POR_TXDIS, POR_TXDIS);
> +
> + if (is_netc_pseudo_port(np))
> + return;
> +
> + netc_port_wait_tx_empty(np, 0);
> + if (np->caps.pmac)
> + netc_port_wait_tx_empty(np, 1);
> +
> + netc_mac_port_rmw(np, NETC_PM_CMD_CFG(0), PM_CMD_CFG_TX_EN, 0);
> +}
> +
> +static void netc_mac_link_up(struct phylink_config *config,
> + struct phy_device *phy, unsigned int mode,
> + phy_interface_t interface, int speed,
> + int duplex, bool tx_pause, bool rx_pause)
> +{
> + struct dsa_port *dp = dsa_phylink_to_port(config);
> + struct netc_port *np;
> +
> + np = NETC_PORT(dp->ds, dp->index);
> + netc_port_set_speed(np, speed);
> +
> + if (phy_interface_mode_is_rgmii(interface))
> + netc_port_set_rgmii_mac(np, speed, duplex);
> +
> + if (interface == PHY_INTERFACE_MODE_RMII ||
> + interface == PHY_INTERFACE_MODE_REVMII ||
> + interface == PHY_INTERFACE_MODE_MII)
> + netc_port_set_rmii_mii_mac(np, speed, duplex);
> +
> + netc_port_mac_tx_enable(np);
> + netc_port_mac_rx_enable(np);
> +}
> +
> +static void netc_mac_link_down(struct phylink_config *config,
> + unsigned int mode,
> + phy_interface_t interface)
> +{
> + struct dsa_port *dp = dsa_phylink_to_port(config);
> + struct netc_port *np;
> +
> + np = NETC_PORT(dp->ds, dp->index);
> + netc_port_mac_rx_graceful_stop(np);
> + netc_port_mac_tx_graceful_stop(np);
> +}
> +
> +static const struct phylink_mac_ops netc_phylink_mac_ops = {
> + .mac_config = netc_mac_config,
> + .mac_link_up = netc_mac_link_up,
> + .mac_link_down = netc_mac_link_down,
> +};
> +
> static const struct dsa_switch_ops netc_switch_ops = {
> .get_tag_protocol = netc_get_tag_protocol,
> .setup = netc_setup,
> .teardown = netc_teardown,
> + .phylink_get_caps = netc_phylink_get_caps,
> };
>
> static int netc_switch_probe(struct pci_dev *pdev,
> @@ -564,6 +806,7 @@ static int netc_switch_probe(struct pci_dev *pdev,
> ds->num_ports = priv->info->num_ports;
> ds->num_tx_queues = NETC_TC_NUM;
> ds->ops = &netc_switch_ops;
> + ds->phylink_mac_ops = &netc_phylink_mac_ops;
> ds->priv = priv;
> priv->ds = ds;
>
> diff --git a/drivers/net/dsa/netc/netc_platform.c b/drivers/net/dsa/netc/netc_platform.c
> index abd599ea9c8d..bb4f92d238cb 100644
> --- a/drivers/net/dsa/netc/netc_platform.c
> +++ b/drivers/net/dsa/netc/netc_platform.c
> @@ -11,8 +11,46 @@ struct netc_switch_platform {
> const struct netc_switch_info *info;
> };
>
> +static void imx94_switch_phylink_get_caps(int port,
> + struct phylink_config *config)
> +{
> + config->mac_capabilities = MAC_1000FD;
> +
> + switch (port) {
> + case 0 ... 1:
> + __set_bit(PHY_INTERFACE_MODE_SGMII,
> + config->supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_2500BASEX,
> + config->supported_interfaces);
> + config->mac_capabilities |= MAC_2500FD;
> + fallthrough;
> + case 2:
> + config->mac_capabilities |= MAC_10 | MAC_100;
> + __set_bit(PHY_INTERFACE_MODE_MII,
> + config->supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_RMII,
> + config->supported_interfaces);
> + /* Port 0 and 1 do not support REVMII */
> + if (port == 2)
> + __set_bit(PHY_INTERFACE_MODE_REVMII,
> + config->supported_interfaces);
> +
> + phy_interface_set_rgmii(config->supported_interfaces);
> + break;
> + case 3: /* CPU port */
> + __set_bit(PHY_INTERFACE_MODE_INTERNAL,
> + config->supported_interfaces);
> + config->mac_capabilities |= MAC_10FD | MAC_100FD |
> + MAC_2500FD;
> + break;
> + default:
> + break;
> + }
> +}
> +
> static const struct netc_switch_info imx94_info = {
> .num_ports = 4,
> + .phylink_get_caps = imx94_switch_phylink_get_caps,
> };
>
> static const struct netc_switch_platform netc_platforms[] = {
> diff --git a/drivers/net/dsa/netc/netc_switch.h b/drivers/net/dsa/netc/netc_switch.h
> index dac19bfba02b..eb65c36ecead 100644
> --- a/drivers/net/dsa/netc/netc_switch.h
> +++ b/drivers/net/dsa/netc/netc_switch.h
> @@ -34,6 +34,7 @@ struct netc_switch;
>
> struct netc_switch_info {
> u32 num_ports;
> + void (*phylink_get_caps)(int port, struct phylink_config *config);
> };
>
> struct netc_port_caps {
> @@ -70,6 +71,9 @@ struct netc_switch {
> struct ntmp_user ntmp;
> };
>
> +#define NETC_PRIV(ds) ((struct netc_switch *)((ds)->priv))
> +#define NETC_PORT(ds, port_id) (NETC_PRIV(ds)->ports[(port_id)])
> +
> /* Write/Read Switch base registers */
> #define netc_base_rd(r, o) netc_read((r)->base + (o))
> #define netc_base_wr(r, o, v) netc_write((r)->base + (o), v)
> diff --git a/drivers/net/dsa/netc/netc_switch_hw.h b/drivers/net/dsa/netc/netc_switch_hw.h
> index 0419f7f9207e..7d9afb493053 100644
> --- a/drivers/net/dsa/netc/netc_switch_hw.h
> +++ b/drivers/net/dsa/netc/netc_switch_hw.h
> @@ -67,6 +67,14 @@
> #define PQOSMR_VQMP GENMASK(19, 16)
> #define PQOSMR_QVMP GENMASK(23, 20)
>
> +#define NETC_POR 0x100
> +#define POR_TXDIS BIT(0)
> +#define POR_RXDIS BIT(1)
> +
> +#define NETC_PSR 0x104
> +#define PSR_TX_BUSY BIT(0)
> +#define PSR_RX_BUSY BIT(1)
> +
> #define NETC_PTCTMSDUR(a) (0x208 + (a) * 0x20)
> #define PTCTMSDUR_MAXSDU GENMASK(15, 0)
> #define PTCTMSDUR_SDU_TYPE GENMASK(17, 16)
> @@ -123,6 +131,24 @@ enum netc_mfo {
> #define NETC_PM_MAXFRM(a) (0x1014 + (a) * 0x400)
> #define PM_MAXFRAM GENMASK(15, 0)
>
> +#define NETC_PM_IEVENT(a) (0x1040 + (a) * 0x400)
> +#define PM_IEVENT_TX_EMPTY BIT(5)
> +#define PM_IEVENT_RX_EMPTY BIT(6)
> +
> +#define NETC_PM_IF_MODE(a) (0x1300 + (a) * 0x400)
> +#define PM_IF_MODE_IFMODE GENMASK(2, 0)
> +#define IFMODE_MII 1
> +#define IFMODE_RMII 3
> +#define IFMODE_RGMII 4
> +#define IFMODE_SGMII 5
> +#define PM_IF_MODE_REVMII BIT(3)
> +#define PM_IF_MODE_M10 BIT(4)
> +#define PM_IF_MODE_HD BIT(6)
> +#define PM_IF_MODE_SSP GENMASK(14, 13)
> +#define SSP_100M 0
> +#define SSP_10M 1
> +#define SSP_1G 2
> +
> #define NETC_PEMDIOCR 0x1c00
> #define NETC_EMDIO_BASE NETC_PEMDIOCR
>
^ permalink raw reply
* Re: [REGRESSION] stmmac: Random DMA reset failure on RK3399 since v6.18
From: Jensen Huang @ 2026-05-07 12:49 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Russell King, Heiner Kallweit, Andrew Lunn, regressions, netdev,
LKML
In-Reply-To: <198e2ce4-07e1-46c0-818d-1eb18645aca0@leemhuis.info>
On Tue, May 5, 2026 at 4:26 PM Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> [Jumping in here, as there are no replies yet]
>
> BTW, Russel, just in case you missed this: looks like this regressions
> caused by a change of yours.
>
> On 4/29/26 14:53, Jensen Huang wrote:
> >
> > I'm reporting a regression on RK3399 (stmmac) observed in v6.18.24.
> > When a network cable is connected during boot, the DMA reset
> > occasionally fails with the error message: "Failed to reset the dma".
> >
> > This appears to be a timing issue related to the EEE RX clock-stop
> > logic. Based on my investigation with the RTL8211E PHY, I monitored
> > the PHY register PS1R (MMD device 3, address 0x01) and observed a
> > value of 0x0f40. This indicates that the PHY is in LPI mode and the RX
> > clock may have already stopped.
> >
> > While commit dd557266cf5f ("net: stmmac: block PHY RXC clock-stop")
>
> Just wondering: have you tried if mainline (e.g. 7.1-rc1) is still
> affected? This is something that is always a good advisable (some people
> would call it required). In this case even more, as it since a while
> contains a fix for the change you mentioned, that wasn't backported:
> c171e679ee66d7 ("net: stmmac: Disable EEE RX clock stop when VLAN is
> enabled"). But this is not my area of expertise (and in different area
> of the code), so that fix might be unrelated to your issue.
Thanks for the pointer.
As you suggested, I have tested the mainline and confirmed that the
issue is not present in v7.1-rc2, nor as early as v6.19-rc1. However,
I verified that the issue persists in the latest stable v6.18.26.
I performed a git bisect and the result pointed exactly to the commit
you mentioned: c171e679ee66d7 ("net: stmmac: Disable EEE RX clock stop
when VLAN is enabled").
Additionally, I tested the case where CONFIG_VLAN_8021Q is not set,
and the DMA reset issue occurs again.
Best regards,
Jensen Huang
>
> Ciao, Thorsten
>
> > ensures the clock is running before the DMA reset, my tests suggest
> > that the phylink_rx_clk_stop_block() call might not provide a
> > sufficiently stable RX clock in time for the immediate DMA reset that
> > follows.
> >
> > Since stmmac already sets mac_requires_rxc = true, I modified
> > phylink_bringup_phy() to honor this flag. This avoids toggling the
> > PHY's clk_stop_enable during the initialization sequence, ensuring the
> > RX clock remains active and stable throughout.
> > With the change below, I achieved 200/200 successful reboots with the
> > cable connected (previously ~50% failure rate).
> >
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -2171,7 +2171,7 @@ static int phylink_bringup_phy(struct phylink
> > *pl, struct phy_device *phy,
> > /* Allow the MAC to stop its clock if the PHY has the capability */
> > pl->mac_tx_clk_stop = phy_eee_tx_clock_stop_capable(phy) > 0;
> >
> > - if (pl->mac_supports_eee_ops) {
> > + if (pl->mac_supports_eee_ops && !pl->config->mac_requires_rxc) {
> > /* Explicitly configure whether the PHY is allowed to stop it's
> > * receive clock.
> > */
> >
> > Any feedback/testing on this would be appreciated.
> >
> > Best regards,
> > Jensen Huang
> >
>
^ permalink raw reply
* [PATCH] RDMA/nldev: add mutual exclusion in nldev_dellink()
From: Edward Adam Davis @ 2026-05-07 12:50 UTC (permalink / raw)
To: syzbot+d8f76778263ab65c2b21
Cc: akpm, arjan, davem, dsahern, edumazet, hdanton, horms, jgg, kuba,
kuni1840, kuniyu, leon, linux-kernel, linux-rdma, netdev, pabeni,
syzkaller-bugs, yanjun.zhu, zyjzyj2000
In-Reply-To: <69fc0c7c.a00a0220.387fc1.0006.GAE@google.com>
We must serialize calls to nldev_dellink() or risk a crash as syzbot
reported:
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
Call Trace:
udp_tunnel_sock_release+0x6d/0x80 net/ipv4/udp_tunnel_core.c:197
rxe_release_udp_tunnel drivers/infiniband/sw/rxe/rxe_net.c:294 [inline]
rxe_sock_put drivers/infiniband/sw/rxe/rxe_net.c:639 [inline]
rxe_net_del+0xfb/0x290 drivers/infiniband/sw/rxe/rxe_net.c:660
rxe_dellink+0x15/0x20 drivers/infiniband/sw/rxe/rxe.c:254
Fixes: a60e3f3d6fba ("RDMA/nldev: Add dellink function pointer")
Reported-by: syzbot+d8f76778263ab65c2b21@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d8f76778263ab65c2b21
Tested-by: syzbot+d8f76778263ab65c2b21@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
drivers/infiniband/core/nldev.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
index 96c745d5bac4..3cb3cb7629fe 100644
--- a/drivers/infiniband/core/nldev.c
+++ b/drivers/infiniband/core/nldev.c
@@ -1816,6 +1816,8 @@ static int nldev_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,
return err;
}
+static DEFINE_MUTEX(nldev_dellink_mutex);
+
static int nldev_dellink(struct sk_buff *skb, struct nlmsghdr *nlh,
struct netlink_ext_ack *extack)
{
@@ -1846,7 +1848,9 @@ static int nldev_dellink(struct sk_buff *skb, struct nlmsghdr *nlh,
* implicitly scoped to the driver supporting dynamic link deletion like RXE.
*/
if (device->link_ops && device->link_ops->dellink) {
+ mutex_lock(&nldev_dellink_mutex);
err = device->link_ops->dellink(device);
+ mutex_unlock(&nldev_dellink_mutex);
if (err)
return err;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH ipsec-next v8 09/14] xfrm: add error messages to state migration
From: Sabrina Dubroca @ 2026-05-07 12:56 UTC (permalink / raw)
To: Antony Antony
Cc: 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, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-9-4578fb016965@secunet.com>
2026-05-05, 06:33:49 +0200, Antony Antony wrote:
> Add descriptive(extack) error messages for all error paths
> in state migration. This improves diagnostics by
> providing clear feedback when migration fails.
>
> After xfrm_init_state() use NL_SET_ERR_MSG_WEAK() as fallback for
> error paths not yet propagating extack e.g. mode_cbs->init_state()
>
> No functional change.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v5->v6: - in case dev_state_add() extack already set
> - after xfrm_init_state() use NL_SET_ERR_MSG_WEAK() as fallback
> v4->v5: - added this patch
> ---
> net/xfrm/xfrm_state.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* Re: [PATCH iwl-net v2] idpf: fix RSS LUT memcpy size
From: Simon Horman @ 2026-05-07 12:54 UTC (permalink / raw)
To: larysa.zaremba
Cc: 'Simon Horman', intel-wired-lan, jacob.e.keller,
przemyslaw.kitszel, andrew+netdev, davem, edumazet, kuba, pabeni,
joshua.a.hay, willemb, netdev, linux-kernel, aleksandr.loktionov,
anthony.l.nguyen
In-Reply-To: <20260504144345.293219-1-larysa.zaremba@intel.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
idpf: fix RSS LUT memcpy size
This commit increases the memcpy size when retrieving the RSS lookup table
to account for the full buffer size rather than just the number of entries.
It also adjusts the required Rx buffer size check to include the structure
size.
Link: https://sashiko.dev/#/patchset/20260323174052.5355-1-larysa.zaremba%40intel.com?part=8
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> index be66f9b2e101c..0fc7c68447f83 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> @@ -2915,8 +2915,9 @@ int idpf_send_get_set_rss_lut_msg(struct idpf_adapter *adapter,
> if (reply_sz < sizeof(struct virtchnl2_rss_lut))
> return -EIO;
>
> - lut_buf_size = le16_to_cpu(recv_rl->lut_entries) * sizeof(u32);
> - if (reply_sz < lut_buf_size)
> + lut_buf_size = flex_array_size(recv_rl, lut,
> + le16_to_cpu(recv_rl->lut_entries));
> + if (reply_sz < lut_buf_size + sizeof(struct virtchnl2_rss_lut))
> return -EIO;
Could this cause an out-of-bounds read if the message size exceeds the
allocated buffer?
Looking at the allocation of recv_rl earlier in this function, it has a
fixed size:
recv_rl = kzalloc(IDPF_CTLQ_MAX_BUF_LEN, GFP_KERNEL);
If the hardware-controlled recv_rl->lut_entries yields a calculated structure
size larger than IDPF_CTLQ_MAX_BUF_LEN, reply_sz may also exceed
IDPF_CTLQ_MAX_BUF_LEN.
While this check ensures reply_sz is large enough for lut_buf_size, does it
ensure we don't read past the end of the IDPF_CTLQ_MAX_BUF_LEN allocation
during the memcpy?
[ ... ]
> @@ -2933,7 +2934,7 @@ int idpf_send_get_set_rss_lut_msg(struct idpf_adapter *adapter,
> }
>
> do_memcpy:
> - memcpy(rss_data->rss_lut, recv_rl->lut, rss_data->rss_lut_size);
> + memcpy(rss_data->rss_lut, recv_rl->lut, lut_buf_size);
Does this copy skip necessary byte-order conversions?
The hardware response recv_rl->lut contains __le32 (little-endian) values,
but the destination rss_data->rss_lut is an array of host-order u32
integers.
The set path correctly applies cpu_to_le32() to elements before sending
them:
rl->lut[i] = rxhash_ena ? cpu_to_le32(rss_data->rss_lut[i]) : 0;
On big-endian architectures, copying little-endian bytes directly with
memcpy() will result in byte-swapped queue indices. Does the driver need to
iterate over the entries and convert each using le32_to_cpu() instead?
^ permalink raw reply
* Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
From: Stefano Garzarella @ 2026-05-07 12:59 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric Dumazet, Arseniy Krasnov, Bobby Eshleman, Stefan Hajnoczi,
David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet, Arseniy Krasnov, Jason Wang, Xuan Zhuo,
Eugenio Pérez, kvm, virtualization
In-Reply-To: <20260507074113-mutt-send-email-mst@kernel.org>
On Thu, May 07, 2026 at 07:45:10AM -0400, Michael S. Tsirkin wrote:
>On Thu, May 07, 2026 at 11:09:47AM +0200, Stefano Garzarella wrote:
>> On Wed, May 06, 2026 at 11:37:45AM -0400, Michael S. Tsirkin wrote:
>> > On Tue, May 05, 2026 at 06:11:13PM +0200, Stefano Garzarella wrote:
>> > > On Tue, May 05, 2026 at 07:14:36AM -0700, Eric Dumazet wrote:
>> > > > On Tue, May 5, 2026 at 6:52 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>> > > > >
>> > > > > On Thu, Apr 30, 2026 at 12:26:52PM +0000, Eric Dumazet 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.
>> > > > > >
>> > > > > >Fix this by estimating the skb metadata size:
>> > > > > >
>> > > > > > (Number of skbs in the queue) * SKB_TRUESIZE(0)
>> > > > > >
>> > > > > >Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
>> > > > > >Signed-off-by: Eric Dumazet <edumazet@google.com>
>> > > > > >Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>> > > > > >Cc: Stefan Hajnoczi <stefanha@redhat.com>
>> > > > > >Cc: Stefano Garzarella <sgarzare@redhat.com>
>> > > > > >Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> > > > > >Cc: Jason Wang <jasowang@redhat.com>
>> > > > > >Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> > > > > >Cc: "Eugenio Pérez" <eperezma@redhat.com>
>> > > > > >Cc: kvm@vger.kernel.org
>> > > > > >Cc: virtualization@lists.linux.dev
>> > > > > >---
>> > > > > > net/vmw_vsock/virtio_transport_common.c | 4 +++-
>> > > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
>> > > > > >
>> > > > > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>> > > > > >index 416d533f493d7b07e9c77c43f741d28cfcd0953e..9b8014516f4fb1130ae184635fbba4dfee58bd64 100644
>> > > > > >--- a/net/vmw_vsock/virtio_transport_common.c
>> > > > > >+++ b/net/vmw_vsock/virtio_transport_common.c
>> > > > > >@@ -447,7 +447,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
>> > > > > > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
>> > > > > > u32 len)
>> > > > > > {
>> > > > > >- if (vvs->buf_used + len > vvs->buf_alloc)
>> > > > > >+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
>> > > > > >+
>> > > > > >+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
>> > > > > > return false;
>> > > > >
>> > > > > I'm not sure about this fix, I mean that maybe this is incomplete.
>> > > > > In virtio-vsock, there is a credit mechanism between the two peers:
>> > > > > https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4850003
>> > > > >
>> > > > > This takes only the payload into account, so it’s true that this problem
>> > > > > exists; however, perhaps we should also inform the other peer of a lower
>> > > > > credit balance, otherwise the other peer will believe it has much more
>> > > > > credit than it actually does, send a large payload, and then the packet
>> > > > > will be discarded and the data lost (there are no retransmissions,
>> > > > > etc.).
>> > > >
>> > > > I dunno, perhaps revert 077706165717 ("virtio/vsock: don't use skbuff
>> > > > state to account credit")
>> > > > and find a better fix then?
>> > >
>> > > IIRC the same issue was there before the commit fixed by that one (commit
>> > > 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")), so
>> > > not sure about reverting it TBH.
>> > >
>> > > CCing Arseniy and Bobby.
>> > >
>> > > >
>> > > > There is always a discrepancy between skb->len and skb->truesize.
>> > > > You will not be able to announce a 1MB window, and accept one milliion
>> > > > skb of 1-byte each.
>> > > >
>> > > > This kind of contract is broken.
>> > > >
>> > >
>> > > Yep, I agree, but before we start discarding data (and losing it), IMHO we
>> > > should at least inform the other peer that we're out of space.
>> > >
>> > > @Stefan, @Michael, do you think we can do something in the spec to avoid
>> > > this issue and in some way take into account also the metadata in the
>> > > credit. I mean to avoid the 1-byte packets flooding.
>> > >
>> > > Thanks,
>> > > Stefano
>> >
>> > Why do we need the metadata? Just don't keep it around if you begin
>> > running low on memory.
>>
>> I don't think removing the skuffs will be easy; we added them for ebpf,
>> zero-copy, and seqpacket as well.
>
>You do not need to remove them completely.
>
>> For now, we're already doing something:
>> merging the skuffs if they don't have EOM set.
>
>
>Right that's good. You could go further and merge with EOM too
>if you stick the info about message boundaries somewhere else.
This adds a lot of complexity IMO, but we can try.
Do you have something in mind?
>
>> As a quick fix, I'm thinking of reducing the `buf_alloc` value to account
>> for the overhead and notifying the other peer, at least until we find a
>> better solution.
>>
>> Stefano
>
>well if you want to support pathological cases such as 1 byte messages
>that would mean like 100x reduction no?
>
Yep, but since this patch is already merged, IMHO that is better than
losing data in those pathological cases.
Thanks,
Stefano
^ permalink raw reply
* [PATCH v2] xprtrdma: Move long delayed work on system_dfl_long_wq
From: Marco Crivellari @ 2026-05-07 13:01 UTC (permalink / raw)
To: linux-kernel, linux-nfs, netdev
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Currently the code enqueue work items using {queue|mod}_delayed_work(),
using system_long_wq. This workqueue should be used when long works are
expected and it is a per-cpu workqueue.
The function(s) end up calling __queue_delayed_work(), which set a global
timer that could fire anywhere, enqueuing the work where the timer fired.
Unbound works could benefit from scheduler task placement, to optimize
performance and power consumption. Long work shouldn't stick to a single
CPU.
Recently, a new unbound workqueue specific for long running work has
been added:
c116737e972e ("workqueue: Add system_dfl_long_wq for long unbound works")
Since the workqueue work doesn't rely on per-cpu variables, there is no
obvious reason that justify the use of a per-cpu workqueue. So change
system_long_wq with system_dfl_long_wq so that the work may benefit from
scheduler task placement.
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
Changes in v2:
- Commit log improvements
- Rebase on v7.1-rc2
Link to v1: https://lore.kernel.org/all/20260430085412.96961-1-marco.crivellari@suse.com/
net/sunrpc/xprtrdma/transport.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 61706df5e485..1a54993f7ffb 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -484,7 +484,8 @@ xprt_rdma_connect(struct rpc_xprt *xprt, struct rpc_task *task)
xprt_reconnect_backoff(xprt, RPCRDMA_INIT_REEST_TO);
}
trace_xprtrdma_op_connect(r_xprt, delay);
- queue_delayed_work(system_long_wq, &r_xprt->rx_connect_worker, delay);
+ queue_delayed_work(system_dfl_long_wq, &r_xprt->rx_connect_worker,
+ delay);
}
/**
--
2.53.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