* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-03-31 13:29 UTC (permalink / raw)
To: Keith Busch
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <acvFV8c5QVxnt3Em@kbusch-mbp>
On Tue, Mar 31, 2026 at 07:00:07AM -0600, Keith Busch wrote:
> On Tue, Mar 31, 2026 at 11:37:58AM +0300, Leon Romanovsky wrote:
> > On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote:
> > >
> > > You're suggesting that Ziping append the new fields to the end of this
> > > struct? I don't think we can modify the layout of a uapi.
> >
> > He needs to add before flex array. This struct is submitted by the user
> > and kernel can easily calculate the position of that array.
>
> No, you can't just do that. Existing applications would break when they
> compile against the updated kernel header. They don't know about this
> new "tph" supplied flag, but they'll all accidently use the new
> dma_ranges offset.
So we need to always pass TPH flag and treat 0 as do-nothing-field.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] pppoe: update Kconfig URLs
From: Dianne Skoll @ 2026-03-31 13:16 UTC (permalink / raw)
To: Jaco Kroon
Cc: Qingfang Deng, linux-ppp, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Eric Biggers, netdev,
linux-kernel, Paul Mackerras, James Carlson
In-Reply-To: <0aa6aa20-0e2a-48e9-8273-53b2fecd287b@uls.co.za>
On Tue, 31 Mar 2026 08:21:40 +0200
Jaco Kroon <jaco@uls.co.za> wrote:
> That same code has recently been dropped from rp-pppoe,
That is not the case. I still ship all of the plugin code with rp-pppoe.
> Most people will never need rp-pppoe.
This is correct because the ppp project *also* ships the plugin code.
Regards,
Dianne.
^ permalink raw reply
* Re: [PATCH] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Russell King (Oracle) @ 2026-03-31 13:25 UTC (permalink / raw)
To: Julian Braha
Cc: manabian, davem, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331125817.117091-1-julianbraha@gmail.com>
On Tue, Mar 31, 2026 at 01:58:17PM +0100, Julian Braha wrote:
> There are already 'if STMMAC_ETH' and 'STMMAC_PLATFORM'
> conditions wrapping these config options, making the
> 'depends on' statements duplicate dependencies (dead code).
>
> I propose leaving the outer 'if STMMAC_PLATFORM...endif' and
> 'if STMMAC_ETH...endif' conditions, and removing the
> individual 'depends on' statements.
>
> This dead code was found by kconfirm, a static analysis tool for Kconfig.
>
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v2] net: phy: realtek: support MDI swapping for RTL8226-CG
From: Paolo Abeni @ 2026-03-31 13:24 UTC (permalink / raw)
To: Jan Hoffmann, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Daniel Golle,
Markus Stockhausen, Damien Dejean
Cc: netdev, linux-kernel
In-Reply-To: <20260327202001.413280-1-jan@3e8.eu>
On 3/27/26 8:32 PM, Jan Hoffmann wrote:
> +static int rtl8226_config_mdi_order(struct phy_device *phydev)
> +{
> + u32 order;
> + int ret;
> +
> + ret = of_property_read_u32(phydev->mdio.dev.of_node, "enet-phy-pair-order", &order);
> +
> + /* Property not present, nothing to do */
> + if (ret == -EINVAL || ret == -ENOSYS)
> + return 0;
> +
> + if (ret)
> + return ret;
> +
> + /* Only enabling MDI swapping is supported */
> + if (order != 1)
> + return -EINVAL;
I guess some existing setup may have "enet-phy-pair-order" == 0, and the
above will make them fail. I think you should just pass with no action
in such a case.
/P
^ permalink raw reply
* [PATCH net-next v2] net: macb: fix use of at91_default_usrio without CONFIG_OF
From: Conor Dooley @ 2026-03-31 13:10 UTC (permalink / raw)
To: netdev
Cc: conor, Conor Dooley, kernel test robot, Jiawen Wu, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Nicolas Ferre, Claudiu Beznea, devicetree, linux-kernel,
linux-riscv
From: Conor Dooley <conor.dooley@microchip.com>
If CONFIG_OF is not enabled, at91_default_usrio is used undeclared in
gem_default_config. Move at91_default_usrio back above the CONFIG_OF
section where macb_default_usrio used to be, so that it is unconditionally
defined and defined prior to any of the users.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603280028.wQjUrIvv-lkp@intel.com/
Reported-by: Jiawen Wu <jiawenwu@trustnetic.com>
Closes: https://lore.kernel.org/all/06a701dcc014$86def5b0$949ce110$@trustnetic.com/
Fixes: a17871778ee28 ("net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
lkp also reported this over the weekend, but against the dev copy in my
tree. I had thought that CONFIG_OF was standard off on x86, but I guess
it isn't, given lkp didn't catch it until randconfigs.
Seem to have come down with some sort of bug, hopefully I haven't cocked
this v2 up somehow in my addled state.
v2:
- Do the boring thing that works... Probably worth a revisit later, cos
there's a bunch of confusing naming here still - "default_gem_config"
is used for cdns,macb and of course "at91_default_usrio" is used on
things where I am reasonably confident it shouldn't, like the Xilinx
boards.
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Nicolas Ferre <nicolas.ferre@microchip.com>
CC: Claudiu Beznea <claudiu.beznea@tuxon.dev>
CC: netdev@vger.kernel.org
CC: devicetree@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux-riscv@lists.infradead.org
---
drivers/net/ethernet/cadence/macb_main.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 12e2b2f4aaf88..3e37b0a3e7e4b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -4949,6 +4949,13 @@ static int macb_init(struct platform_device *pdev,
return macb_init_dflt(pdev);
}
+static const struct macb_usrio_config at91_default_usrio = {
+ .mii = MACB_BIT(MII),
+ .rmii = MACB_BIT(RMII),
+ .rgmii = GEM_BIT(RGMII),
+ .clken = MACB_BIT(CLKEN),
+};
+
#if defined(CONFIG_OF)
/* 1518 rounded up */
#define AT91ETHER_MAX_RBUFF_SZ 0x600
@@ -5523,13 +5530,6 @@ static int eyeq5_init(struct platform_device *pdev)
return ret;
}
-static const struct macb_usrio_config at91_default_usrio = {
- .mii = MACB_BIT(MII),
- .rmii = MACB_BIT(RMII),
- .rgmii = GEM_BIT(RGMII),
- .clken = MACB_BIT(CLKEN),
-};
-
static const struct macb_usrio_config mpfs_usrio = {
.tsu_source = 0,
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Russell King (Oracle) @ 2026-03-31 13:07 UTC (permalink / raw)
To: Jiawen Wu
Cc: netdev, Mengyuan Lou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jacob Keller,
Abdun Nihaal, stable
In-Reply-To: <D56A7C3379B4DA62+20260331071107.5414-1-jiawenwu@trustnetic.com>
On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> For the copper NIC with external PHY, the driver called
> phylink_connect_phy() during probe and phylink_disconnect_phy() during
> remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> upon module remove.
>
> To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
Wouldn't it be simpler to just wrap the phylink_disconnect_phy() in the
remove function with rtnl_lock()..rtnl_unlock() ?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v6 04/11] net: ngbe: implement libwx reset ops
From: Andrew Lunn @ 2026-03-31 13:03 UTC (permalink / raw)
To: Jiawen Wu
Cc: 'Jakub Kicinski', netdev, mengyuanlou, andrew+netdev,
davem, edumazet, pabeni, richardcochran, linux, horms,
michal.swiatkowski, jacob.e.keller, kees, joe, larysa.zaremba,
abdun.nihaal, leitao
In-Reply-To: <073601dcc0de$a87b2e30$f9718a90$@trustnetic.com>
> > static inline int wx_set_state_reset(struct wx *wx)
> > {
> > u8 timeout = 50;
> >
> > while (test_and_set_bit(WX_STATE_RESETTING, wx->state)) {
> > timeout--;
> > if (!timeout)
> > return -EBUSY;
> >
> > usleep_range(1000, 2000);
> > }
> >
> > return 0;
> > }
At minimum, this should use one of the helpers from iopoll.h.
Andrew
^ permalink raw reply
* Re: [PATCH v9 net-next 2/5] psp: add new netlink cmd for dev-assoc and dev-disassoc
From: Daniel Zahka @ 2026-03-31 13:03 UTC (permalink / raw)
To: Wei Wang, netdev, Jakub Kicinski, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman
Cc: Wei Wang
In-Reply-To: <20260330223143.2394706-3-weibunny.kernel@gmail.com>
On 3/30/26 6:31 PM, Wei Wang wrote:
> + -
> + name: dev-assoc
> + doc: Associate a network device with a PSP device.
> + attribute-set: dev
> + do:
> + request:
> + attributes:
> + - id
> + - ifindex
> + - nsid
> + reply:
> + attributes: []
> + pre: psp-device-get-locked
> + post: psp-device-unlock
> + -
> + name: dev-disassoc
> + doc: Disassociate a network device from a PSP device.
> + attribute-set: dev
> + do:
> + request:
> + attributes:
> + - id
> + - ifindex
> + - nsid
> + reply:
> + attributes: []
> + pre: psp-device-get-locked
> + post: psp-device-unlock
>
Not sure where we ended up on the netns isolation model, but I'll just
note that these ops are not "admin" so they can be done from any netns.
I don't think that's an issue per se, but I wonder if someone with a
different use case will come along down the road and want to go for the
more restrictive deployment option.
>
> + list_for_each_entry_safe(entry, entry_tmp, &psd->assoc_dev_list,
> + dev_list) {
> + list_del(&entry->dev_list);
> + rcu_assign_pointer(entry->assoc_dev->psp_dev, NULL);
> + netdev_put(entry->assoc_dev, &entry->dev_tracker);
> + kfree(entry);
> + }
> +
> rcu_assign_pointer(psd->main_netdev->psp_dev, NULL);
>
> psd->ops = NULL;
> @@ -361,5 +381,4 @@ static int __init psp_init(void)
>
> return genl_register_family(&psp_nl_family);
> }
> -
> subsys_initcall(psp_init);
nit: spurious line deletion
> +int psp_nl_dev_assoc_doit(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct psp_dev *psd = info->user_ptr[0];
> + struct psp_assoc_dev *psp_assoc_dev;
> + struct net_device *assoc_dev;
> + u32 assoc_ifindex;
> + struct sk_buff *rsp;
nit: reverse xmas issue
> +
> +int psp_nl_dev_disassoc_doit(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct psp_assoc_dev *entry, *found = NULL;
> + struct psp_dev *psd = info->user_ptr[0];
> + u32 assoc_ifindex;
> + struct sk_buff *rsp;
nit: reverse xmas issue
^ permalink raw reply
* Re: [PATCH net] net: txgbe: fix RTNL assertion warning when remove module
From: Andrew Lunn @ 2026-03-31 13:00 UTC (permalink / raw)
To: Jiawen Wu
Cc: netdev, Mengyuan Lou, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Russell King, Simon Horman,
Jacob Keller, Abdun Nihaal, stable
In-Reply-To: <D56A7C3379B4DA62+20260331071107.5414-1-jiawenwu@trustnetic.com>
On Tue, Mar 31, 2026 at 03:11:07PM +0800, Jiawen Wu wrote:
> For the copper NIC with external PHY, the driver called
> phylink_connect_phy() during probe and phylink_disconnect_phy() during
> remove. It caused an RTNL assertion warning in phylink_disconnect_phy()
> upon module remove.
>
> To fix this, move the phylink connect/disconnect PHY to ndo_open/close.
>
> ------------[ cut here ]------------
> RTNL: assertion failed at drivers/net/phy/phylink.c (2351)
> WARNING: drivers/net/phy/phylink.c:2351 at
> phylink_disconnect_phy+0xd8/0xf0 [phylink], CPU#0: rmmod/4464
> Modules linked in: ...
> CPU: 0 UID: 0 PID: 4464 Comm: rmmod Kdump: loaded Not tainted 7.0.0-rc4+
> Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING
> PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024
> RIP: 0010:phylink_disconnect_phy+0xe4/0xf0 [phylink]
> Code: 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 f6 31 ff e9 3a 38 8f e7
> 48 8d 3d 48 87 e2 ff ba 2f 09 00 00 48 c7 c6 c1 22 24 c0 <67> 48 0f b9 3a
> e9 34 ff ff ff 66 90 90 90 90 90 90 90 90 90 90 90
> RSP: 0018:ffffce7288363ac0 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff89654b2a1a00 RCX: 0000000000000000
> RDX: 000000000000092f RSI: ffffffffc02422c1 RDI: ffffffffc0239020
> RBP: ffffce7288363ae8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8964c4022000
> R13: ffff89654fce3028 R14: ffff89654ebb4000 R15: ffffffffc0226348
> FS: 0000795e80d93780(0000) GS:ffff896c52857000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005b528b592000 CR3: 0000000170d0f000 CR4: 0000000000f50ef0
> PKRU: 55555554
> Call Trace:
> <TASK>
> txgbe_remove_phy+0xbb/0xd0 [txgbe]
> txgbe_remove+0x4c/0xb0 [txgbe]
> pci_device_remove+0x41/0xb0
> device_remove+0x43/0x80
> device_release_driver_internal+0x206/0x270
> driver_detach+0x4a/0xa0
> bus_remove_driver+0x83/0x120
> driver_unregister+0x2f/0x60
> pci_unregister_driver+0x40/0x90
> txgbe_driver_exit+0x10/0x850 [txgbe]
> __do_sys_delete_module.isra.0+0x1c3/0x2f0
> __x64_sys_delete_module+0x12/0x20
> x64_sys_call+0x20c3/0x2390
> do_syscall_64+0x11c/0x1500
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_syscall_64+0x15a/0x1500
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_fault+0x312/0x580
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? __handle_mm_fault+0x9d5/0x1040
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? count_memcg_events+0x101/0x1d0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? handle_mm_fault+0x1e8/0x2f0
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? do_user_addr_fault+0x2f8/0x820
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? irqentry_exit+0xb2/0x600
> ? srso_alias_return_thunk+0x5/0xfbef5
> ? exc_page_fault+0x92/0x1c0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Fixes: 02b2a6f91b90 ("net: txgbe: support copper NIC with external PHY")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Keith Busch @ 2026-03-31 13:00 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <20260331083758.GA814676@unreal>
On Tue, Mar 31, 2026 at 11:37:58AM +0300, Leon Romanovsky wrote:
> On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote:
> >
> > You're suggesting that Ziping append the new fields to the end of this
> > struct? I don't think we can modify the layout of a uapi.
>
> He needs to add before flex array. This struct is submitted by the user
> and kernel can easily calculate the position of that array.
No, you can't just do that. Existing applications would break when they
compile against the updated kernel header. They don't know about this
new "tph" supplied flag, but they'll all accidently use the new
dma_ranges offset.
> Something like this:
> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> index b1d658b8f7b51..d78d915992232 100644
> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> @@ -237,7 +237,11 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> if (get_dma_buf.region_index >= VFIO_PCI_ROM_REGION_INDEX)
> return -ENODEV;
>
> - dma_ranges = memdup_array_user(&arg->dma_ranges, get_dma_buf.nr_ranges,
> + if (!tph_supplied)
> + dma_ranges = memdup_array_user(old_dma_ranges_pos, get_dma_buf.nr_ranges,
> + sizeof(*dma_ranges));
> + else
> + dma_ranges = memdup_array_user(&arg->dma_ranges, get_dma_buf.nr_ranges,
> sizeof(*dma_ranges));
> if (IS_ERR(dma_ranges))
> return PTR_ERR(dma_ranges);
> ~
^ permalink raw reply
* [PATCH] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Julian Braha @ 2026-03-31 12:58 UTC (permalink / raw)
To: manabian, davem, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32
Cc: netdev, linux-arm-kernel, linux-kernel, Julian Braha
There are already 'if STMMAC_ETH' and 'STMMAC_PLATFORM'
conditions wrapping these config options, making the
'depends on' statements duplicate dependencies (dead code).
I propose leaving the outer 'if STMMAC_PLATFORM...endif' and
'if STMMAC_ETH...endif' conditions, and removing the
individual 'depends on' statements.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index c2cb530fd0a2..ba5473b8dae0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -20,7 +20,6 @@ if STMMAC_ETH
config STMMAC_SELFTESTS
bool "Support for STMMAC Selftests"
depends on INET
- depends on STMMAC_ETH
default n
help
This adds support for STMMAC Selftests using ethtool. Enable this
@@ -29,7 +28,6 @@ config STMMAC_SELFTESTS
config STMMAC_PLATFORM
tristate "STMMAC Platform bus support"
- depends on STMMAC_ETH
select MFD_SYSCON
default y
help
@@ -53,7 +51,6 @@ config DWMAC_DWC_QOS_ETH
config DWMAC_GENERIC
tristate "Generic driver for DWMAC"
- default STMMAC_PLATFORM
help
Generic DWMAC driver for platforms that don't require any
platform specific code to function or is using platform
@@ -336,7 +333,6 @@ config DWMAC_IMX8
config DWMAC_INTEL_PLAT
tristate "Intel dwmac support"
depends on OF && COMMON_CLK
- depends on STMMAC_ETH
help
Support for ethernet controllers on Intel SoCs
@@ -371,7 +367,7 @@ config DWMAC_VISCONTI
help
Support for ethernet controller on Visconti SoCs.
-endif
+endif # STMMAC_PLATFORM
config STMMAC_LIBPCI
tristate
@@ -381,7 +377,7 @@ config STMMAC_LIBPCI
config DWMAC_INTEL
tristate "Intel GMAC support"
default X86
- depends on X86 && STMMAC_ETH && PCI
+ depends on X86 && PCI
depends on COMMON_CLK
depends on ACPI
help
@@ -420,4 +416,4 @@ config STMMAC_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
-endif
+endif # STMMAC_ETH
--
2.51.2
^ permalink raw reply related
* Re: [PATCH net-next V9 12/14] net/mlx5: qos: Support cross-device tx scheduling
From: Cosmin Ratiu @ 2026-03-31 12:57 UTC (permalink / raw)
To: Tariq Toukan, kuba@kernel.org
Cc: allison.henderson@oracle.com, Moshe Shemesh, jiri@resnulli.us,
davem@davemloft.net, daniel.zahka@gmail.com,
donald.hunter@gmail.com, netdev@vger.kernel.org,
matttbe@kernel.org, pabeni@redhat.com, horms@kernel.org,
Parav Pandit, corbet@lwn.net, kees@kernel.org, willemb@google.com,
Dragos Tatulea, razor@blackwall.org, Adithya Jayachandran,
Dan Jurgens, leon@kernel.org, vadim.fedorenko@linux.dev,
linux-kernel@vger.kernel.org, Saeed Mahameed, shuah@kernel.org,
andrew+netdev@lunn.ch, Mark Bloch, Jiri Pirko, Carolina Jubran,
Shahar Shitrit, daniel@iogearbox.net, minhquangbui99@gmail.com,
Nimrod Oren, dw@davidwei.uk, jacob.e.keller@intel.com,
skhan@linuxfoundation.org, Petr Machata, edumazet@google.com,
antonio@openvpn.net, mst@redhat.com,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org,
Shay Drori, sdf@fomichev.me, chuck.lever@oracle.com, Gal Pressman,
joe@dama.to, linux-doc@vger.kernel.org
In-Reply-To: <20260331020820.3525138-1-kuba@kernel.org>
On Mon, 2026-03-30 at 19:08 -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net/mlx5: qos: Support cross-device tx scheduling
>
> This commit relaxes the restriction that rate groups can only contain
> vports
> from the same E-Switch. It enables cross-device TX scheduling if the
> hardware
> supports it, LAG is enabled, and the E-Switches share a devlink
> device.
>
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
>
> [ ... ]
>
> > @@ -1738,18 +1761,44 @@ int mlx5_esw_devlink_rate_node_del(struct
> > devlink_rate *rate_node, void *priv,
> > return 0;
> > }
> >
> > +static int
> > +mlx5_esw_validate_cross_esw_scheduling(struct mlx5_eswitch *esw,
> > + struct mlx5_esw_sched_node
> > *parent,
> > + struct netlink_ext_ack
> > *extack)
> > +{
>
> [ ... ]
>
> > + if (!mlx5_lag_is_active(esw->dev)) {
> > + NL_SET_ERR_MSG_MOD(extack,
> > + "Cross E-Switch scheduling
> > requires LAG to be activated");
> > + return -EOPNOTSUPP;
> > + }
>
> What happens to the cross-device rate scheduling if LAG is
> deactivated
> after the configuration is applied?
>
> When LAG is deactivated, the LAG state is torn down in hardware, but
> there
> does not appear to be a corresponding cleanup or update triggered for
> the
> cross-eswitch QoS scheduling elements.
>
> Could this result in a regression where the hardware TSAR tree and
> devlink
> rate configuration remain pointing to a now-invalid VHCA association,
> bypassing the state validation and causing traffic drops or firmware
> errors?
This has been considered, and FW rejects LAG deactivation while there
are VFs present on any of the ports. VFs need to be removed first, and
removing all VF will also remove the QoS tree entirely.
SW could perhaps make this nicer by detecting that the QoS tree spans
multiple devices and issuing a warning before attempting to invoke the
DESTROY_LAG FW command. But this appears to be a significant effort
currently, since the LAG code isn't structured in a way that would make
this easy.
>
> > +
> > + return 0;
> > +}
Cosmin.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Russell King (Oracle) @ 2026-03-31 12:57 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Maxime Chevallier, Andrew Lunn, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <20260331123858.1912449-3-charles.perry@microchip.com>
On Tue, Mar 31, 2026 at 05:38:54AM -0700, Charles Perry wrote:
> + if (!(bus->phy_ignore_ta_mask & 1 << mii_id) &&
> + !FIELD_GET(MDIO_READOK_BIT, val)) {
> + dev_dbg(&bus->dev, "READOK bit cleared\n");
> + return -EIO;
> + }
> +
> + ret = FIELD_GET(MDIO_RDATA_MASK, val);
> +
> + return ret;
You don't need "ret" here, this can simply be:
return FIELD_GET(MDIO_RDATA_MASK, val);
...
> + writel(MDIO_TRIGGER_BIT | FIELD_PREP(MDIO_REG_DEV_ADDR_MASK, regnum) |
> + FIELD_PREP(MDIO_PHY_PRT_ADDR_MASK, mii_id) |
> + FIELD_PREP(MDIO_OPERATION_MASK, MDIO_OPERATION_WRITE) |
> + FIELD_PREP(MDIO_START_OF_FRAME_MASK, 1),
> + priv->regs + MDIO_REG_FRAME_CFG_2);
Shouldn't this wait for the write to complete?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix posted write support for sideband queue operations
From: Korba, Przemyslaw @ 2026-03-31 12:56 UTC (permalink / raw)
To: Keller, Jacob E, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw
In-Reply-To: <dbe4af5f-b8c6-4abe-bd55-8f970e18add9@intel.com>
> -----Original Message-----
> From: Keller, Jacob E <jacob.e.keller@intel.com>
> Sent: Thursday, March 26, 2026 12:42 AM
> To: Korba, Przemyslaw <przemyslaw.korba@intel.com>; intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: fix posted write support for sideband queue operations
>
> On 3/19/2026 4:13 AM, Przemyslaw Korba wrote:
> > On E830, PTP time adjustment commands sent via
> > SBQ don't generate completion responses, causing the driver to
> > timeout waiting and return -EIO, when trying:
> >
> Hm. Is this really for E830? I didn't realize that device actually
> sends SBQ commands for PTP?
>
> According to ice_ptp_adj_clock for E830, it says "E830 sync PHYs
> automatically after setting GLTSYN_SHADJ".
>
> Did you mean E825-C here? Can you confirm the device type affected? Or
> am I missing something?
>
> > phc_ctl eth8 get adj 2 get
> > dmesg: ice 0000:1a:00.0: PTP failed to adjust time, err -5
> >
> > Add support for posted mode not to wait for completion response.
> >
> > Fixes: 8f5ee3c477a8 ("ice: add support for sideband messages")
> > Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com>
> > ---
> > v2:
> > - change "postpone" to "posted"
> > - init struct with {} instead of {0}
> > v1:
> > https://lore.kernel.org/intel-wired-lan/20260310110700.345904-1-przemyslaw.korba@intel.com/
> >
> > drivers/net/ethernet/intel/ice/ice_common.c | 7 ++++++-
> > drivers/net/ethernet/intel/ice/ice_controlq.c | 4 ++++
> > drivers/net/ethernet/intel/ice/ice_controlq.h | 1 +
> > 3 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c
> > index 8866902efb91..c89c6ca1281b 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_common.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_common.c
> > @@ -1765,6 +1765,7 @@ int ice_sbq_rw_reg(struct ice_hw *hw, struct ice_sbq_msg_input *in, u16 flags)
> > {
>
> This affects the ice_sbq_rw_reg function which is used by several
> variants including the E822 devices, E825-C with ETH56G, and even E810
> devices.
>
> Do all these devices not provide completion? Or do we simply not care
> about waiting?
>
> I don't see a single call to ice_sbq_rw_reg for E830, so I suspect this
> is correct but for a different device, and the commit message is just a
> typo?
Hi Jake,
Thanks for review! Grzegorz's patch he mentioned indeed makes it so E830 uses this functionality.
You are right there are other devices we need to consider. I've found more complete Karol's patch that does exactly that, but got stuck on reviews:
https://lore.kernel.org/intel-wired-lan/20250520110823.1937981-7-karol.kolacinski@intel.com/
I addressed past reviews, and will try to merge this patch, I sent updated version to our internal mailing list for review : )
>
> > struct ice_sbq_cmd_desc desc = {0};
> > struct ice_sbq_msg_req msg = {0};
> > + struct ice_sq_cd cd = {};
> > u16 msg_len;
> > int status;
> >
> > @@ -1785,10 +1786,14 @@ int ice_sbq_rw_reg(struct ice_hw *hw, struct ice_sbq_msg_input *in, u16 flags)
> > */
> > msg_len -= sizeof(msg.data);
> >
> > + if (in->opcode == ice_sbq_msg_wr)
> > + cd.posted = 1;
> > +
> > desc.flags = cpu_to_le16(flags);
> > desc.opcode = cpu_to_le16(ice_sbq_opc_neigh_dev_req);
> > desc.param0.cmd_len = cpu_to_le16(msg_len);
> > - status = ice_sbq_send_cmd(hw, &desc, &msg, msg_len, NULL);
> > + status = ice_sbq_send_cmd(hw, &desc, &msg, msg_len, &cd);
> > +
> > if (!status && !in->opcode)
> > in->data = le32_to_cpu
> > (((struct ice_sbq_msg_cmpl *)&msg)->data);
> > diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c b/drivers/net/ethernet/intel/ice/ice_controlq.c
> > index dcb837cadd18..a6008dc77fa4 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_controlq.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
> > @@ -1086,6 +1086,10 @@ ice_sq_send_cmd(struct ice_hw *hw, struct ice_ctl_q_info *cq,
> > wr32(hw, cq->sq.tail, cq->sq.next_to_use);
> > ice_flush(hw);
> >
> > + /* If the message is posted, don't wait for completion. */
> > + if (cd && cd->posted)
> > + goto sq_send_command_error;
> > +
> > /* Wait for the command to complete. If it finishes within the
> > * timeout, copy the descriptor back to temp.
> > */
> > diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.h b/drivers/net/ethernet/intel/ice/ice_controlq.h
> > index 788040dd662e..c50d6fcbacba 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_controlq.h
> > +++ b/drivers/net/ethernet/intel/ice/ice_controlq.h
> > @@ -77,6 +77,7 @@ struct ice_ctl_q_ring {
> > /* sq transaction details */
> > struct ice_sq_cd {
> > struct libie_aq_desc *wb_desc;
> > + u8 posted : 1;
> > };
> >
> > /* rq event information */
> >
> > base-commit: acd2abc52dea91c3bc3d1b6dd8a92b9631d48bbf
^ permalink raw reply
* Re: [PATCH net-next V9 11/14] net/mlx5: qos: Remove qos domains and use shd lock
From: Cosmin Ratiu @ 2026-03-31 12:53 UTC (permalink / raw)
To: Tariq Toukan, kuba@kernel.org
Cc: allison.henderson@oracle.com, Moshe Shemesh, jiri@resnulli.us,
davem@davemloft.net, daniel.zahka@gmail.com,
donald.hunter@gmail.com, netdev@vger.kernel.org,
matttbe@kernel.org, pabeni@redhat.com, horms@kernel.org,
Parav Pandit, corbet@lwn.net, kees@kernel.org, willemb@google.com,
Dragos Tatulea, razor@blackwall.org, Adithya Jayachandran,
Dan Jurgens, leon@kernel.org, vadim.fedorenko@linux.dev,
linux-kernel@vger.kernel.org, Saeed Mahameed, shuah@kernel.org,
andrew+netdev@lunn.ch, Mark Bloch, Jiri Pirko, Carolina Jubran,
Shahar Shitrit, daniel@iogearbox.net, minhquangbui99@gmail.com,
Nimrod Oren, dw@davidwei.uk, jacob.e.keller@intel.com,
skhan@linuxfoundation.org, Petr Machata, edumazet@google.com,
antonio@openvpn.net, mst@redhat.com,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org,
Shay Drori, sdf@fomichev.me, chuck.lever@oracle.com, Gal Pressman,
joe@dama.to, linux-doc@vger.kernel.org
In-Reply-To: <20260331020817.3525089-1-kuba@kernel.org>
On Mon, 2026-03-30 at 19:08 -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net/mlx5: qos: Remove qos domains and use shd lock
>
> This commit removes QoS domains and switches to using the shd lock to
> protect against concurrent QoS modifications. It also enables the
> supported_cross_device_rate_nodes devlink ops attribute.
>
> Link:
> https://lore.kernel.org/netdev/20250213180134.323929-1-tariqt@nvidia.com/
>
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> > index 6698ac55a4bfa..c051605fecd23 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/devlink.c
> > @@ -385,6 +385,7 @@ static const struct devlink_ops
> > mlx5_devlink_ops = {
> > .rate_node_del = mlx5_esw_devlink_rate_node_del,
> > .rate_leaf_parent_set =
> > mlx5_esw_devlink_rate_leaf_parent_set,
> > .rate_node_parent_set =
> > mlx5_esw_devlink_rate_node_parent_set,
> > + .supported_cross_device_rate_nodes = true,
>
> The commit message states that enabling
> supported_cross_device_rate_nodes
> now is safe because mlx5_esw_qos_vport_update_parent rejects cross-
> esw
> parent updates.
>
> When a user provides a DEVLINK_ATTR_PARENT_DEV belonging to an
> unrelated
> device, the devlink core (devlink_nl_rate_parent_node_set) drops the
> lock on
> the parent devlink and calls devlink_rate_node_get_by_name(). This
> function
> traverses the rate_list of the unlocked parent devlink instance.
>
> Does this leave the devlink core exposed to data races and potential
> use-after-free vulnerabilities, since the driver's rejection callback
> executes only after this lockless list traversal has occurred?
I will address this by adding common ancestor validation in devlink
rate core, which was missing.
>
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > index 0be516003bcde..f67f99428959f 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/qos.c
> > @@ -1110,7 +1068,7 @@ void mlx5_esw_qos_vport_disable(struct
> > mlx5_vport *vport)
> > struct mlx5_esw_sched_node *parent;
> >
> > lockdep_assert_held(&esw->state_lock);
> > - esw_qos_lock(esw);
> > + devl_lock(esw->dev->shd);
>
> Could esw->dev->shd be NULL here?
>
> In mlx5_shd_init(), initialization is explicitly skipped for non-PF
> devices,
> meaning Sub-Functions (SFs) acting as E-Switch managers will have a
> NULL
> shd pointer. If the device lacks VPD data, pci_vpd_alloc() returns -
> ENODEV,
> causing mlx5_shd_init() to return 0 but leaving dev->shd as NULL.
>
> When QoS operations are attempted on these devices, calling
> devl_lock()
> dereferences the pointer, which could cause an immediate NULL pointer
> dereference and kernel panic.
Right. This is a race with Jiri's fix ([1]), which changed the
assumption this code was architected with that dev->shd is always
initialized. That is no longer the case, and the consequence is that
this needs to 1) not unconditionally use dev->shd and 2) use a fallback
lock when it isn't available.
>
> Additionally, this acquires the devlink lock while already holding
> esw->state_lock, establishing the lock order:
> state_lock -> devlink->lock.
>
> Conversely, the devlink core invokes driver callbacks with the
> devlink
> instance lock held, and the driver subsequently acquires esw-
> >state_lock
> inside these callbacks, creating the reverse order:
> devlink->lock -> state_lock.
>
> Does this introduce a circular locking dependency splat between
> state_lock
> and the devlink instance lock?
This claim is based on the incorrect assumption that devlink instances
share the same lock class, while in fact each is unique. The
established lock order is devlink->lock -> state_lock and this doesn't
conflict with state_lock -> shd->lock.
>
> > @@ -1159,26 +1117,25 @@ int mlx5_esw_qos_set_vport_rate(struct
> > mlx5_vport *vport, u32 max_rate, u32 min_
> > struct mlx5_eswitch *esw = vport->dev->priv.eswitch;
> > int err;
> >
> > - esw_qos_lock(esw);
> > + devl_lock(esw->dev->shd);
>
> This function is invoked by mlx5_eswitch_set_vport_rate(), which acts
> as the
> handler for the ndo_set_vf_rate netdev callback. The core network
> stack
> executes ndo_set_vf_rate with the rtnl_lock held, establishing the
> lock
> order: rtnl_lock -> devlink->lock.
>
> However, the devlink subsystem enforces the opposite locking order
> (devlink->lock -> rtnl_lock). Because all devlink locks share the
> same
> lockdep class, does this inversion trigger a circular locking
> dependency
> lockdep splat and pose an ABBA deadlock risk?
Same as above, there's no ABBA here since devlink instances use
different lock classes.
Perhaps Sashiko (I think) could be taught this to reduce false
positives?
>
> [ ... ]
>
> > @@ -1859,13 +1763,15 @@ mlx5_esw_qos_vport_update_parent(struct
> > mlx5_vport *vport,
> > parent ? : esw-
> > >qos.root,
> > extack);
> > }
> > - esw_qos_unlock(esw);
> > +
> > return err;
> > }
> >
> > void mlx5_esw_qos_vport_clear_parent(struct mlx5_vport *vport)
> > {
> > + devl_lock(vport->dev->shd);
> > mlx5_esw_qos_vport_update_parent(vport, NULL, NULL);
> > + devl_unlock(vport->dev->shd);
> > }
>
> During device teardown, execution paths such as
> mlx5_unload_one_devl_locked()
> hold the primary devlink instance lock. This path invokes
> mlx5_eswitch_unload_vf_vports() ->
> mlx5_esw_offloads_devlink_port_unregister()
> -> mlx5_esw_qos_vport_clear_parent().
>
> Because both the primary devlink instance lock and the shd devlink
> instance
> lock are initialized from the same site (devlink_alloc), they share
> the same
> lockdep class.
>
> Does calling devl_lock() directly (instead of using the devlink
> core's
> mutex_lock_nested capability) while a lock of the same class is
> already held
> trigger a recursive locking lockdep warning?
Again, same false positive. Devlinks use unique lock classes.
Cosmin.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Andrew Lunn @ 2026-03-31 12:51 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Maxime Chevallier, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <20260331123858.1912449-3-charles.perry@microchip.com>
On Tue, Mar 31, 2026 at 05:38:54AM -0700, Charles Perry wrote:
> This adds an MDIO driver for PIC64-HPSC/HX. The hardware supports C22
> and C45 but only C22 is implemented in this commit.
>
> This MDIO hardware is based on a Microsemi design supported in Linux by
> mdio-mscc-miim.c. However, The register interface is completely
> different with pic64hpsc, hence the need for a separate driver.
>
> The documentation recommends an input clock of 156.25MHz and a prescaler
> of 39, which yields an MDIO clock of 1.95MHz.
>
> The hardware supports an interrupt pin or a "TRIGGER" bit that can be
> polled to signal transaction completion. This commit uses polling.
>
> This was tested on Microchip HB1301 evalkit with a VSC8574 and a
> VSC8541.
>
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] net/ipv6: repeat route lookup with saddr set for ECMP
From: Maximilian Moehl @ 2026-03-31 12:50 UTC (permalink / raw)
To: Paolo Abeni, Maximilian Moehl, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Simon Horman
Cc: netdev, linux-kernel
In-Reply-To: <f73c3cf9-18e9-4109-b173-d6000cb0cf88@redhat.com>
On Mon Mar 30, 2026 at 9:56 AM CEST, Paolo Abeni wrote:
> On 3/29/26 11:12 AM, Maximilian Moehl wrote:
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index 8e2a6b28cea7..465fce51d017 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -1148,6 +1148,18 @@ static int ip6_dst_lookup_tail(struct net *net, const struct sock *sk,
>> *dst = NULL;
>> }
>>
>> + /* If ECMP was involved the initial hash was calculted
>> + * with saddr=:: which can result in instability
>> + * when it is later re-calculated with the selected
>> + * saddr. Lookup the route again with the chosen
>> + * saddr to get a stable result.
>> + */
>> + if (fl6->mp_hash) {
>> + fl6->mp_hash = 0;
>> + dst_release(*dst);
>> + *dst = NULL;
>> + }
>> +
>> if (fl6->flowi6_oif)
>> flags |= RT6_LOOKUP_F_IFACE;
>> }
>
> This apparently breaks ipv6 fib tests (fib_tests.sh):
>
> # IPv6 multipath load balance test
> # TEST: IPv6 multipath loadbalance [FAIL]
>
> see
> https://github.com/linux-netdev/nipa/wiki/How-to-run-netdev-selftests-CI-style
> on how to reproduce the tests.
>
> Also this would deserve additional testcases.
Thank you for the pointer, I will look into the tests.
> Without diving much inside the code I have the feeling this change is
> plugged into the wrong place: multipath selection logic should be
> encapsulated by fib6_select_path().
To be able to move this logic into fib6_select_path(), the call to
ip6_route_get_saddr() would probably have to move as well as we need
to set the source address after the first lookup. This would then also
set the source address as a side-effect.
I can give this a try, just want to confirm that it's the correct way
before doing so or if I'm missing something.
--
Max
^ permalink raw reply
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Fernando Fernandez Mancera @ 2026-03-31 12:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, horms, pabeni, kuba, davem, dsahern, Yiming Qian
In-Reply-To: <CANn89iLJUi+cA4fFr7XQESkT+5ckY6+MGg7QEM-G123RzuD5RQ@mail.gmail.com>
On 3/31/26 2:13 PM, Eric Dumazet wrote:
> On Tue, Mar 31, 2026 at 5:00 AM Fernando Fernandez Mancera
> <fmancera@suse.de> wrote:
>>
>> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
>> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
>> single nexthops and small Equal-Cost Multi-Path groups, this fixed
>> allocation fails for large nexthop groups like 512+ nexthops.
>>
>> This results in the following warning splat:
>>
>> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
>> [...]
>> RIP: 0010:rtm_get_nexthop+0x176/0x1c0
>> [...]
>> Call Trace:
>> <TASK>
>> rtnetlink_rcv_msg+0x168/0x670
>> netlink_rcv_skb+0x5c/0x110
>> netlink_unicast+0x203/0x2e0
>> netlink_sendmsg+0x222/0x460
>> ____sys_sendmsg+0x35a/0x380
>> ___sys_sendmsg+0x99/0xe0
>> __sys_sendmsg+0x8a/0xf0
>> do_syscall_64+0x12f/0x1590
>> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> </TASK>
>
> I find these stack traces without symbols not very useful.
Hi Eric,
sure, here is the decoded trace:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0,
CPU#20: rep/4608
RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395 (discriminator 2))
Call Trace:
<TASK>
rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
netlink_unicast (net/netlink/af_netlink.c:1319
net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
____sys_sendmsg (net/socket.c:721 (discriminator 16) net/socket.c:736
(discriminator 16) net/socket.c:2585 (discriminator 16))
___sys_sendmsg (net/socket.c:2641)
__sys_sendmsg (net/socket.c:2671 (discriminator 1))
do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1)
arch/x86/entry/syscall_64.c:94 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
>
> Any reason you have not used scripts/decode_stacktrace.sh ?
>
Not really, in the past I checked other commits with `git log --grep
"Call Trace"` and found out that most of the traces did not have symbols
so I decided to attach the raw trace.
I do not really have a personal preference here. If trace with symbols
is preferred I will do it like that in the future. I could also send a
V2 of this patch if needed.
Thanks!
Fernando.
^ permalink raw reply
* Re: [PATCH] [v3] dpaa2: avoid linking objects into multiple modules
From: Ioana Ciornei @ 2026-03-31 12:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King, Arnd Bergmann, netdev, linux-kernel
In-Reply-To: <20260330140818.1081987-1-arnd@kernel.org>
On Mon, Mar 30, 2026 at 04:07:29PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Each object file contains information about which module it gets linked
> into, so linking the same file into multiple modules now causes a warning:
>
> scripts/Makefile.build:254: drivers/net/ethernet/freescale/dpaa2/Makefile: dpaa2-mac.o is added to multiple modules: fsl-dpaa2-eth fsl-dpaa2-switch
> scripts/Makefile.build:254: drivers/net/ethernet/freescale/dpaa2/Makefile: dpmac.o is added to multiple modules: fsl-dpaa2-eth fsl-dpaa2-switch
>
> Change the way that dpaa2 is built by moving the two common files into a
> separate module with exported symbols instead.
>
> To avoid a link failure when the switch driver is built-in, but the dpio driver
> is a loadable module, add the same dependency in there that exists for
> the ethernet driver.
This paragraph is no longer needed since the change was integrated
already.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
With the paragraph above removed:
Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
^ permalink raw reply
* Re: [PATCH net-next V9 07/14] devlink: Allow rate node parents from other devlinks
From: Cosmin Ratiu @ 2026-03-31 12:44 UTC (permalink / raw)
To: Tariq Toukan, kuba@kernel.org
Cc: allison.henderson@oracle.com, Moshe Shemesh, jiri@resnulli.us,
davem@davemloft.net, daniel.zahka@gmail.com,
donald.hunter@gmail.com, netdev@vger.kernel.org,
matttbe@kernel.org, pabeni@redhat.com, horms@kernel.org,
Parav Pandit, corbet@lwn.net, kees@kernel.org, willemb@google.com,
Dragos Tatulea, razor@blackwall.org, Adithya Jayachandran,
Dan Jurgens, leon@kernel.org, vadim.fedorenko@linux.dev,
linux-kernel@vger.kernel.org, Saeed Mahameed, shuah@kernel.org,
andrew+netdev@lunn.ch, Mark Bloch, Jiri Pirko, Carolina Jubran,
Shahar Shitrit, daniel@iogearbox.net, minhquangbui99@gmail.com,
Nimrod Oren, dw@davidwei.uk, jacob.e.keller@intel.com,
skhan@linuxfoundation.org, Petr Machata, edumazet@google.com,
antonio@openvpn.net, mst@redhat.com,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org,
Shay Drori, sdf@fomichev.me, chuck.lever@oracle.com, Gal Pressman,
joe@dama.to, linux-doc@vger.kernel.org
In-Reply-To: <20260331020814.3525053-1-kuba@kernel.org>
On Mon, 2026-03-30 at 19:08 -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> devlink: Allow rate node parents from other devlinks
>
> This commit makes use of the building blocks previously added to
> implement cross-device rate nodes.
>
> > diff --git a/include/net/devlink.h b/include/net/devlink.h
> > index 3038af6ec017e..8d5ad5d4f1d05 100644
> > --- a/include/net/devlink.h
> > +++ b/include/net/devlink.h
> > @@ -1585,6 +1585,11 @@ struct devlink_ops {
> > struct devlink_rate *parent,
> > void *priv_child, void
> > *priv_parent,
> > struct netlink_ext_ack
> > *extack);
> > + /* Indicates if cross-device rate nodes are supported.
> > + * This also requires a shared common ancestor object all
> > devices that
> > + * could share rate nodes are nested in.
> > + */
> > + bool supported_cross_device_rate_nodes;
>
> When a device acting as a cross-device rate parent is destroyed,
> devl_rate_nodes_destroy() iterates the shared rate_list to detach its
> children. If it encounters a child rate node belonging to a different
> device,
> it invokes the child driver's ops->rate_node_parent_set or
> ops->rate_leaf_parent_set callbacks.
>
> Since the cleanup path only holds the parent's devlink lock and the
> shared
> root devlink lock, does this allow the child driver's rate operations
> to
> execute concurrently with other operations on the child device
> without holding
> the child's devlink instance lock?
The rate_node lock protects changes to the rate hierarchy, even if
child devlink instance locks aren't held. The code works by locking
everything from the affected instance A up to the instance at the root
of the hierarchy R, and affects the hierarchy with R's instance lock
held. I think this can be made clearer in the code/comments though, so
Will tweak some things in the next version.
>
> [ ... ]
> > diff --git a/net/devlink/rate.c b/net/devlink/rate.c
> > index 1949746fab291..f243cccc95bee 100644
> > --- a/net/devlink/rate.c
> > +++ b/net/devlink/rate.c
> > @@ -30,19 +30,53 @@ devlink_rate_leaf_get_from_info(struct devlink
> > *devlink, struct genl_info *info)
> > return devlink_rate ?: ERR_PTR(-ENODEV);
> > }
> >
> > +/* Repeatedly locks the nested-in devlink instances while cross
> > device rate
> > + * nodes are supported. Returns the devlink instance where rates
> > should be
> > + * stored.
> > + */
> > static struct devlink *devl_rate_lock(struct devlink *devlink)
> > {
> > - return devlink;
> > + struct devlink *rate_devlink = devlink;
> > +
> > + while (rate_devlink->ops &&
> > + rate_devlink->ops-
> > >supported_cross_device_rate_nodes) {
> > + devlink = devlink_nested_in_get_lock(rate_devlink-
> > >rel);
> > + if (!devlink)
> > + break;
> > + rate_devlink = devlink;
> > + }
> > + return rate_devlink;
> > }
>
> [ ... ]
>
> > +/* Repeatedly unlocks the nested-in devlink instances of 'devlink'
> > while cross
> > + * device nodes are supported.
> > + */
> > static void devl_rate_unlock(struct devlink *devlink)
> > {
> > + if (!devlink || !devlink->ops ||
> > + !devlink->ops->supported_cross_device_rate_nodes)
> > + return;
> > +
> > + devl_rate_unlock(devlink_nested_in_get_locked(devlink-
> > >rel));
> > + devlink_nested_in_put_unlock(devlink->rel);
> > }
>
> If a parent devlink is not yet registered,
> devlink_nested_in_get_lock() can
> return NULL in devl_rate_lock() and break the loop without taking a
> lock.
>
> If another thread completes registering the parent devlink
> concurrently,
> devlink_nested_in_get_locked() in devl_rate_unlock() will find it.
>
> Could this lead to unlocking a mutex that was never acquired and
> dropping a
> reference that was never taken, resulting in a use-after-free or lock
> corruption?
A valid concern in theory, even though in practice there won't be
another thread registering a shared devlink instance that would race
with registration in this way.
I will make these lock/unlock helpers more robust in the next version.
>
> [ ... ]
> > @@ -320,13 +371,14 @@ devlink_nl_rate_parent_node_set(struct
> > devlink_rate *devlink_rate,
> > struct genl_info *info,
> > struct nlattr *nla_parent)
> > {
> > - struct devlink *devlink = devlink_rate->devlink;
> > + struct devlink *devlink = devlink_rate->devlink,
> > *parent_devlink;
> > const char *parent_name = nla_data(nla_parent);
> > const struct devlink_ops *ops = devlink->ops;
> > size_t len = strlen(parent_name);
> > struct devlink_rate *parent;
> > int err = -EOPNOTSUPP;
> >
> > + parent_devlink = devlink_nl_ctx(info)->parent_devlink ? :
> > devlink;
> > parent = devlink_rate->parent;
> >
> > if (parent && !len) {
> > @@ -344,7 +396,13 @@ devlink_nl_rate_parent_node_set(struct
> > devlink_rate *devlink_rate,
> > refcount_dec(&parent->refcnt);
> > devlink_rate->parent = NULL;
> > } else if (len) {
> > - parent = devlink_rate_node_get_by_name(devlink,
> > parent_name);
> > + /* parent_devlink (when different than devlink)
> > isn't locked,
> > + * but the rate node devlink instance is, so
> > nobody from the
> > + * same group of devices sharing rates could
> > change the used
> > + * fields or unregister the parent.
> > + */
> > + parent =
> > devlink_rate_node_get_by_name(parent_devlink,
> > +
> > parent_name);
>
> Is parent_devlink validated to ensure it shares the same common rate
> root
> ancestor as devlink?
>
> If an arbitrary unrelated parent_devlink is specified,
> devlink_rate_node_get_by_name() could traverse an unrelated parent's
> rate_list that was never locked by devl_rate_lock(), leading to a
> data race.
>
> Additionally, if a rate node is found, its priv pointer is passed to
> the
> target driver's ops->rate_node_parent_set. Could this cause the
> target driver
> to cast a foreign priv pointer to its own private struct type,
> resulting in
> type confusion and memory corruption?
Right, there's no common ancestor validation which could lead to
unpleasant results if one tries to set a rate parent across drivers
which support cross-esw.
I'll add it in the next version.
Cosmin.
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: microchip: enable downshift by default on LAN88xx
From: Nicolai Buchwitz @ 2026-03-31 12:41 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: netdev, Phil Elwell, Andrew Lunn, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <acu3jgGklIfDVp-m@shell.armlinux.org.uk>
On 31.3.2026 14:01, Russell King (Oracle) wrote:
> On Tue, Mar 31, 2026 at 01:58:55PM +0200, Nicolai Buchwitz wrote:
>> On 31.3.2026 13:32, Russell King (Oracle) wrote:
>> > On Tue, Mar 31, 2026 at 12:46:27AM +0200, Nicolai Buchwitz wrote:
>> > > Enable auto-downshift from 1000BASE-T to 100BASE-TX after 2 failed
>> > > auto-negotiation attempts by default. This ensures that links with
>> > > faulty or missing cable pairs (C and D) fall back to 100Mbps without
>> > > requiring userspace configuration.
>> > >
>> > > Users can override or disable downshift at runtime:
>> > >
>> > > ethtool --set-phy-tunable eth0 downshift off
>> > >
>> > > Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
>> > > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> >
>> > I'm slightly concerned by this commit. ->config_init() is called when
>> > the netdev attaches the PHY, and also during the resume path - and it's
>> > the second one which I believe is a problem here.
>> >
>> > If the user has configured the downshift, it is reasonable for the user
>> > to expect the setting to be preserved over a suspend/resume. However,
>> > by placing this code in ->config_init(), you will overwrite the user's
>> > setting when the system resumes.
>>
>> You have a valid point. Looking at other drivers, Marvell has the
>> same issue: m88e1112_config_init() unconditionally sets downshift to 3
>> on every config_init call.
>>
>> I see two options:
>>
>> 1. Save the user's setting in the driver's priv struct and restore it
>> in config_init instead of blindly applying the default.
>>
>> 2. Handle it generically in the PHY core, saving/restoring tunable
>> state across suspend/resume for all drivers.
>>
>> I'd lean towards (1) to keep this series simple. (2) could be a
>> follow-up that fixes Marvell and others too. What do you think?
>
> Or (3) configure the default it in the probe function?
Unfortunately the driver has .soft_reset = genphy_soft_reset which
runs before config_init on resume and would clear the setting? So
config_init still needs to set it.
Nicolai
^ permalink raw reply
* [PATCH net-next v3 2/2] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-03-31 12:38 UTC (permalink / raw)
To: netdev
Cc: Charles Perry, Maxime Chevallier, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel
In-Reply-To: <20260331123858.1912449-1-charles.perry@microchip.com>
This adds an MDIO driver for PIC64-HPSC/HX. The hardware supports C22
and C45 but only C22 is implemented in this commit.
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely
different with pic64hpsc, hence the need for a separate driver.
The documentation recommends an input clock of 156.25MHz and a prescaler
of 39, which yields an MDIO clock of 1.95MHz.
The hardware supports an interrupt pin or a "TRIGGER" bit that can be
polled to signal transaction completion. This commit uses polling.
This was tested on Microchip HB1301 evalkit with a VSC8574 and a
VSC8541.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
Notes:
Changes in v3:
- Add a MAINTAINERS entry (Jakub)
Changes in v2:
- Remove #define for unused registers (Maxime)
- Add "c22" to clause 22 read/write ops (Maxime)
- Remove the call to platform_set_drvdata() (Andrew)
- Make the clock mandatory (Andrew)
- Use 2.5MHz if no clock-frequency was specified (Andrew)
- Change the error message for bad clock-frequency (Andrew)
- Fix a use without initialization on bus_freq (Andrew)
MAINTAINERS | 6 +
drivers/net/mdio/Kconfig | 7 ++
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/mdio-pic64hpsc.c | 192 ++++++++++++++++++++++++++++++
4 files changed, 206 insertions(+)
create mode 100644 drivers/net/mdio/mdio-pic64hpsc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e08767323763..9297c46dba91 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17216,6 +17216,12 @@ L: linux-serial@vger.kernel.org
S: Maintained
F: drivers/tty/serial/8250/8250_pci1xxxx.c
+MICROCHIP PIC64-HPSC/HX DRIVERS
+M: Charles Perry <charles.perry@microchip.com>
+S: Supported
+F: Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
+F: drivers/net/mdio/mdio-pic64hpsc.c
+
MICROCHIP POLARFIRE FPGA DRIVERS
M: Conor Dooley <conor.dooley@microchip.com>
L: linux-fpga@vger.kernel.org
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 44380378911b..7bdba8c3ddef 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -146,6 +146,13 @@ config MDIO_OCTEON
buses. It is required by the Octeon and ThunderX ethernet device
drivers on some systems.
+config MDIO_PIC64HPSC
+ tristate "PIC64-HPSC/HX MDIO interface support"
+ depends on HAS_IOMEM && OF_MDIO
+ help
+ This driver supports the MDIO interface found on the PIC64-HPSC/HX
+ SoCs.
+
config MDIO_IPQ4019
tristate "Qualcomm IPQ4019 MDIO interface support"
depends on HAS_IOMEM && OF_MDIO
diff --git a/drivers/net/mdio/Makefile b/drivers/net/mdio/Makefile
index fbec636700e7..048586746026 100644
--- a/drivers/net/mdio/Makefile
+++ b/drivers/net/mdio/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
obj-$(CONFIG_MDIO_MSCC_MIIM) += mdio-mscc-miim.o
obj-$(CONFIG_MDIO_MVUSB) += mdio-mvusb.o
obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
+obj-$(CONFIG_MDIO_PIC64HPSC) += mdio-pic64hpsc.o
obj-$(CONFIG_MDIO_REALTEK_RTL9300) += mdio-realtek-rtl9300.o
obj-$(CONFIG_MDIO_REGMAP) += mdio-regmap.o
obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
diff --git a/drivers/net/mdio/mdio-pic64hpsc.c b/drivers/net/mdio/mdio-pic64hpsc.c
new file mode 100644
index 000000000000..0ca6f5af5396
--- /dev/null
+++ b/drivers/net/mdio/mdio-pic64hpsc.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Microchip PIC64-HPSC/HX MDIO controller driver
+ *
+ * Copyright (c) 2026 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_mdio.h>
+#include <linux/platform_device.h>
+
+#define MDIO_REG_PRESCALER 0x20
+#define MDIO_CFG_PRESCALE_MASK GENMASK(7, 0)
+
+#define MDIO_REG_FRAME_CFG_1 0x24
+#define MDIO_WDATA_MASK GENMASK(15, 0)
+
+#define MDIO_REG_FRAME_CFG_2 0x28
+#define MDIO_TRIGGER_BIT BIT(31)
+#define MDIO_REG_DEV_ADDR_MASK GENMASK(20, 16)
+#define MDIO_PHY_PRT_ADDR_MASK GENMASK(8, 4)
+#define MDIO_OPERATION_MASK GENMASK(3, 2)
+#define MDIO_START_OF_FRAME_MASK GENMASK(1, 0)
+
+/* Possible value of MDIO_OPERATION_MASK */
+#define MDIO_OPERATION_WRITE BIT(0)
+#define MDIO_OPERATION_READ BIT(1)
+
+#define MDIO_REG_FRAME_STATUS 0x2C
+#define MDIO_READOK_BIT BIT(24)
+#define MDIO_RDATA_MASK GENMASK(15, 0)
+
+struct pic64hpsc_mdio_dev {
+ void __iomem *regs;
+};
+
+static int pic64hpsc_mdio_wait_trigger(struct mii_bus *bus)
+{
+ struct pic64hpsc_mdio_dev *priv = bus->priv;
+ u32 val;
+ int ret;
+
+ /* The MDIO_TRIGGER bit returns 0 when a transaction has completed. */
+ ret = readl_poll_timeout(priv->regs + MDIO_REG_FRAME_CFG_2, val,
+ !(val & MDIO_TRIGGER_BIT), 50, 10000);
+
+ if (ret < 0)
+ dev_dbg(&bus->dev, "TRIGGER bit timeout: %x\n", val);
+
+ return ret;
+}
+
+static int pic64hpsc_mdio_c22_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct pic64hpsc_mdio_dev *priv = bus->priv;
+ u32 val;
+ int ret;
+
+ ret = pic64hpsc_mdio_wait_trigger(bus);
+ if (ret)
+ return ret;
+
+ writel(MDIO_TRIGGER_BIT | FIELD_PREP(MDIO_REG_DEV_ADDR_MASK, regnum) |
+ FIELD_PREP(MDIO_PHY_PRT_ADDR_MASK, mii_id) |
+ FIELD_PREP(MDIO_OPERATION_MASK, MDIO_OPERATION_READ) |
+ FIELD_PREP(MDIO_START_OF_FRAME_MASK, 1),
+ priv->regs + MDIO_REG_FRAME_CFG_2);
+
+ ret = pic64hpsc_mdio_wait_trigger(bus);
+ if (ret)
+ return ret;
+
+ val = readl(priv->regs + MDIO_REG_FRAME_STATUS);
+
+ /* The MDIO_READOK is a 1-bit value reflecting the inverse of the MDIO
+ * bus value captured during the 2nd TA cycle. A PHY/Port should drive
+ * the MDIO bus with a logic 0 on the 2nd TA cycle, however, the
+ * PHY/Port could optionally drive a logic 1, to communicate a read
+ * failure. This feature is optional, not defined by the 802.3 standard
+ * and not supported in standard external PHYs.
+ */
+ if (!(bus->phy_ignore_ta_mask & 1 << mii_id) &&
+ !FIELD_GET(MDIO_READOK_BIT, val)) {
+ dev_dbg(&bus->dev, "READOK bit cleared\n");
+ return -EIO;
+ }
+
+ ret = FIELD_GET(MDIO_RDATA_MASK, val);
+
+ return ret;
+}
+
+static int pic64hpsc_mdio_c22_write(struct mii_bus *bus, int mii_id, int regnum,
+ u16 value)
+{
+ struct pic64hpsc_mdio_dev *priv = bus->priv;
+ int ret;
+
+ ret = pic64hpsc_mdio_wait_trigger(bus);
+ if (ret < 0)
+ return ret;
+
+ writel(FIELD_PREP(MDIO_WDATA_MASK, value),
+ priv->regs + MDIO_REG_FRAME_CFG_1);
+
+ writel(MDIO_TRIGGER_BIT | FIELD_PREP(MDIO_REG_DEV_ADDR_MASK, regnum) |
+ FIELD_PREP(MDIO_PHY_PRT_ADDR_MASK, mii_id) |
+ FIELD_PREP(MDIO_OPERATION_MASK, MDIO_OPERATION_WRITE) |
+ FIELD_PREP(MDIO_START_OF_FRAME_MASK, 1),
+ priv->regs + MDIO_REG_FRAME_CFG_2);
+
+ return 0;
+}
+
+static int pic64hpsc_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct pic64hpsc_mdio_dev *priv;
+ struct mii_bus *bus;
+ unsigned long rate;
+ struct clk *clk;
+ u32 bus_freq;
+ u32 div;
+ int ret;
+
+ bus = devm_mdiobus_alloc_size(dev, sizeof(*priv));
+ if (!bus)
+ return -ENOMEM;
+
+ priv = bus->priv;
+
+ priv->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->regs))
+ return PTR_ERR(priv->regs);
+
+ bus->name = KBUILD_MODNAME;
+ bus->read = pic64hpsc_mdio_c22_read;
+ bus->write = pic64hpsc_mdio_c22_write;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
+ bus->parent = dev;
+
+ clk = devm_clk_get_enabled(dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ if (of_property_read_u32(np, "clock-frequency", &bus_freq))
+ bus_freq = 2500000;
+
+ rate = clk_get_rate(clk);
+
+ div = DIV_ROUND_UP(rate, 2 * bus_freq) - 1;
+ if (div == 0 || div & ~MDIO_CFG_PRESCALE_MASK) {
+ dev_err(dev, "MDIO clock-frequency out of range\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(dev, "rate=%lu bus_freq=%u real_bus_freq=%lu div=%u\n", rate,
+ bus_freq, rate / (2 * (1 + div)), div);
+ writel(div, priv->regs + MDIO_REG_PRESCALER);
+
+ ret = devm_of_mdiobus_register(dev, bus, np);
+ if (ret) {
+ dev_err(dev, "Cannot register MDIO bus (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id pic64hpsc_mdio_match[] = {
+ { .compatible = "microchip,pic64hpsc-mdio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, pic64hpsc_mdio_match);
+
+static struct platform_driver pic64hpsc_mdio_driver = {
+ .probe = pic64hpsc_mdio_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = pic64hpsc_mdio_match,
+ },
+};
+module_platform_driver(pic64hpsc_mdio_driver);
+
+MODULE_AUTHOR("Charles Perry <charles.perry@microchip.com>");
+MODULE_DESCRIPTION("Microchip PIC64-HPSC/HX MDIO driver");
+MODULE_LICENSE("GPL");
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v3 1/2] dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-03-31 12:38 UTC (permalink / raw)
To: netdev
Cc: Charles Perry, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree, linux-kernel
In-Reply-To: <20260331123858.1912449-1-charles.perry@microchip.com>
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for separate documentation.
The hardware supports C22 and C45.
The documentation recommends an input clock of 156.25MHz and a prescaler
of 39, which yields an MDIO clock of 1.95MHz.
The hardware supports an interrupt pin to signal transaction completion
which is not strictly needed as the software can also poll a "TRIGGER"
bit for this.
Signed-off-by: Charles Perry <charles.perry@microchip.com>
---
Notes:
Changes in v3: none
Changes in v2:
- Make "clocks" and "interrupts" required (Andrew)
- Add a default value to "clock-frequency" (Andrew)
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
new file mode 100644
index 000000000000..d690afe3d3cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC64-HPSC/HX MDIO controller
+
+maintainers:
+ - Charles Perry <charles.perry@microchip.com>
+
+description: |
+ Microchip PIC64-HPSC/HX SoCs have two MDIO bus controller. This MDIO bus
+ controller supports C22 and C45 register access. It is named "MDIO Initiator"
+ in the documentation.
+
+allOf:
+ - $ref: mdio.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: microchip,pic64hpsc-mdio
+ - items:
+ - const: microchip,pic64hx-mdio
+ - const: microchip,pic64hpsc-mdio
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ default: 2500000
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ mdio@4000C21E000 {
+ compatible = "microchip,pic64hpsc-mdio";
+ reg = <0x400 0x0C21E000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&svc_clk>;
+ interrupt-parent = <&saplic0>;
+ interrupts = <168 IRQ_TYPE_LEVEL_HIGH>;
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+ };
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v3 0/2] Add support for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-03-31 12:38 UTC (permalink / raw)
To: netdev
Cc: Charles Perry, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Russell King, devicetree
Hello,
This series adds a driver for the two MDIO controllers of PIC64-HPSC/HX.
The hardware supports C22 and C45 but only C22 is implemented for now.
This MDIO hardware is based on a Microsemi design supported in Linux by
mdio-mscc-miim.c. However, The register interface is completely different
with pic64hpsc, hence the need for a separate driver.
The documentation recommends an input clock of 156.25MHz and a prescaler of
39, which yields an MDIO clock of 1.95MHz.
This was tested on Microchip HB1301 evalkit which has a VSC8574 and a
VSC8541 with clock frequencies of 0.6, 1.95 and 2.5 MHz.
Thanks,
Charles
Changes in v3:
- 2/2: Add a MAINTAINERS entry (Jakub)
Changes in v2:
- 1/2: Make "clocks" and "interrupts" required (Andrew)
- 1/2: Add a default value to "clock-frequency" (Andrew)
- 2/2: Remove #define for unused registers (Maxime)
- 2/2: Add "c22" to clause 22 read/write ops (Maxime)
- 2/2: Remove the call to platform_set_drvdata() (Andrew)
- 2/2: Make the clock mandatory (Andrew)
- 2/2: Use 2.5MHz if no clock-frequency was specified (Andrew)
- 2/2: Change the error message for bad clock-frequency (Andrew)
- 2/2: Fix a use without initialization on bus_freq (Andrew)
CC: Andrew Lunn <andrew+netdev@lunn.ch>
CC: "David S. Miller" <davem@davemloft.net>
CC: Eric Dumazet <edumazet@google.com>
CC: Jakub Kicinski <kuba@kernel.org>
CC: Paolo Abeni <pabeni@redhat.com>
CC: Rob Herring <robh@kernel.org>
CC: Krzysztof Kozlowski <krzk+dt@kernel.org>
CC: Conor Dooley <conor+dt@kernel.org>
CC: Heiner Kallweit <hkallweit1@gmail.com>
CC: Russell King <linux@armlinux.org.uk>
CC: netdev@vger.kernel.org
CC: devicetree@vger.kernel.org
Charles Perry (2):
dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
.../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
MAINTAINERS | 6 +
drivers/net/mdio/Kconfig | 7 +
drivers/net/mdio/Makefile | 1 +
drivers/net/mdio/mdio-pic64hpsc.c | 192 ++++++++++++++++++
5 files changed, 274 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
create mode 100644 drivers/net/mdio/mdio-pic64hpsc.c
--
2.47.3
^ permalink raw reply
* Re: [BUG] vsock: refcount_t saturation and OOM via buffer size invariant inversion
From: Stefano Garzarella @ 2026-03-31 12:37 UTC (permalink / raw)
To: Norbert Szetei
Cc: davem, edumazet, kuba, pabeni, horms, virtualization, netdev,
linux-kernel, John Villamil
In-Reply-To: <523A8D3C-F4D9-43DD-A3A6-01C9EC335656@doyensec.com>
On Tue, Mar 24, 2026 at 06:28:12PM +0100, Norbert Szetei wrote:
>Hello,
>
>we have discovered a bug in AF_VSOCK where an unprivileged user can bypass socket
>memory constraints. This leads to refcount_t saturation and OOM. While
>refcount_t prevents a true UAF by saturating, the resulting state triggers
>kernel warnings and kernel panic, depending on the setup.
>
>In vsock_connectible_setsockopt(), the SO_VM_SOCKETS_BUFFER_MIN_SIZE
>and
>SO_VM_SOCKETS_BUFFER_MAX_SIZE options are used to update the buffer's minimum
>and maximum values independently.
>
>The vsock_update_buffer_size() function clamps the buffer size to the maximum
>first, then the minimum:
>
>// https://github.com/torvalds/linux/blob/c369299895a591d96745d6492d4888259b004a9e/net/vmw_vsock/af_vsock.c#L1950
>if (val > vsk->buffer_max_size)
> val = vsk->buffer_max_size;
>
>if (val < vsk->buffer_min_size)
> val = vsk->buffer_min_size;
>
>vsk->buffer_size = val;
>
>By setting buffer_min_size to a large value, the second clamp overrides the
>first, forcing vsk->buffer_size to exceed the intended maximum. The transport
>layer then uses this value, allowing unbounded SKB allocation that saturates the
>32-bit sk_wmem_alloc refcount.
>
>The fix should ensure that SO_VM_SOCKETS_BUFFER_MIN_SIZE cannot be used to set a
>value higher than the current buffer_max_size. Conversely,
>SO_VM_SOCKETS_BUFFER_MAX_SIZE should not be allowed to be set lower than the
>current buffer_min_size.
Okay, but that wouldn't change much. As long as the user sets the
maximum to match the minimum you set in the POC, it behaves exactly the
same way, right?
Maybe we should add a sysctl to set a global upper bound, but this is
another problem, I agree that we should improve the kernel behavior
around min/max. I see 3 options:
1. Just invert the checks, fist check for min, then for max.
2. Simply adjust the min and max values so that they make sense. For
example, if the minimum value being set is greater than the maximum, the
kernel could adjust the maximum to the same value. However, this would
not change the behavior of your POC.
3. Force the minimum to be less than or equal to the maximum. This,
however, would require a certain order when setting the minimum and
maximum, especially relative to the default. For example, if you
increase the minimum beyond the default maximum, you must adjust the
maximum first; conversely, if you want to set the maximum below the
default minimum, you must adjust the minimum first.
I'm more into 1 or 2. 3 IMO is too much.
Do you want to send a patch?
Thanks,
Stefano
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox