* Re: [PATCH net v2 1/2] net: phylink: call phy_init_hw() in phylink resume path
From: Russell King (Oracle) @ 2026-04-09 10:42 UTC (permalink / raw)
To: Ovidiu Panait
Cc: andrew, hkallweit1, davem, edumazet, kuba, pabeni, biju.das.jz,
netdev, linux-kernel, linux-renesas-soc
In-Reply-To: <20260409095633.70973-2-ovidiu.panait.rb@renesas.com>
On Thu, Apr 09, 2026 at 09:56:32AM +0000, Ovidiu Panait wrote:
> When mac_managed_pm flag is set, mdio_bus_phy_resume() is skipped,
> so phy_init_hw(), which performs soft_reset and config_init, is not
> called during resume.
>
> This is inconsistent with the non-mac_managed_pm path, where
> mdio_bus_phy_resume() calls phy_init_hw() before phy_resume()
> on every resume.
>
> Add phy_init_hw() calls in both phylink_prepare_resume() and
> phylink_resume(), to ensure that the PHY state is the same as
> when the PHY is resumed via the MDIO bus.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> ---
> drivers/net/phy/phylink.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 087ac63f9193..c302126009f6 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -2669,8 +2669,10 @@ void phylink_prepare_resume(struct phylink *pl)
> * then resume the PHY. Note that 802.3 allows PHYs 500ms before
> * the clock meets requirements. We do not implement this delay.
> */
> - if (pl->config->mac_requires_rxc && phydev && phydev->suspended)
> + if (pl->config->mac_requires_rxc && phydev && phydev->suspended) {
> + phy_init_hw(phydev);
> phy_resume(phydev);
I'm going to make an alternative suggestion - should we combine
phy_init_hw() and phy_resume() to ensure that all MAC drivers that
call phy_resume() correctly initialise the PHY first?
Looking at the callers of phy_resume():
- drivers/net/ethernet/nxp/lpc_eth.c - calls phy_resume() from
lpc_eth_open() but no call to phy_init_hw(). Not used in
suspend/resume paths, so presumably uses the built-in phylib
handling that does call phy_init_hw() before phy_resume().
- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c - suspends
and then immediately resumes the PHY before enabling loopback. Seems
like a PHY workaround that should've been handled in the PHY driver.
Suspends the PHY when loopback is disabled (which looks buggy.)
- drivers/net/ethernet/hisilicon/hns/hns_ethtool.c - resumes the PHY
when enabling loopback and suspends the PHY when loopback is
disabled. (what if the netdev is already up? Also looks buggy to me.)
- drivers/net/ethernet/broadcom/genet/bcmgenet.c - bcmgenet_resume()
calls phy_init_hw() before a conditional call to phy_resume(). I
don't see a matching call to phy_suspend(). If the bcmgenet device
may wakeup the system, then wouldn't the PHY configuration be
preserved over suspend/resume making the call to phy_init_hw() also
unnecessary if device_may_wakeup(d) returns true?
- drivers/net/ethernet/broadcom/bcmsysport.c - no call to phy_init_hw()
before phy_resume().
- drivers/net/ethernet/realtek/r8169_main.c - calls phy_init_hw()
immediately before phy_resume().
--
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
* [PATCH v2] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Weiming Shi @ 2026-04-09 10:49 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Phil Sutter, Simon Horman, netfilter-devel, coreteam, netdev,
Xiang Mei, Weiming Shi
nft_fwd_neigh can be used in egress chains (NF_NETDEV_EGRESS). When the
forwarding rule targets the same device or two devices forward to each
other, neigh_xmit() triggers dev_queue_xmit() which re-enters
nf_hook_egress(), causing infinite recursion and stack overflow.
Move the nf_get_nf_dup_skb_recursion() accessor and NF_RECURSION_LIMIT
to the shared header nf_dup_netdev.h as a static inline, so that
nft_fwd_netdev can use the recursion counter directly without exported
function call overhead. Guard neigh_xmit() with the same recursion
limit already used in nf_do_netdev_egress().
Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
include/net/netfilter/nf_dup_netdev.h | 13 +++++++++++++
net/netfilter/nf_dup_netdev.c | 16 ----------------
net/netfilter/nft_fwd_netdev.c | 7 +++++++
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
index b175d271aec9..609bcf422a9b 100644
--- a/include/net/netfilter/nf_dup_netdev.h
+++ b/include/net/netfilter/nf_dup_netdev.h
@@ -3,10 +3,23 @@
#define _NF_DUP_NETDEV_H_
#include <net/netfilter/nf_tables.h>
+#include <linux/netdevice.h>
+#include <linux/sched.h>
void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
+#define NF_RECURSION_LIMIT 2
+
+static inline u8 *nf_get_nf_dup_skb_recursion(void)
+{
+#ifndef CONFIG_PREEMPT_RT
+ return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
+#else
+ return ¤t->net_xmit.nf_dup_skb_recursion;
+#endif
+}
+
struct nft_offload_ctx;
struct nft_flow_rule;
diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
index fab8b9011098..a958a1b0c5be 100644
--- a/net/netfilter/nf_dup_netdev.c
+++ b/net/netfilter/nf_dup_netdev.c
@@ -13,22 +13,6 @@
#include <net/netfilter/nf_tables_offload.h>
#include <net/netfilter/nf_dup_netdev.h>
-#define NF_RECURSION_LIMIT 2
-
-#ifndef CONFIG_PREEMPT_RT
-static u8 *nf_get_nf_dup_skb_recursion(void)
-{
- return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
-}
-#else
-
-static u8 *nf_get_nf_dup_skb_recursion(void)
-{
- return ¤t->net_xmit.nf_dup_skb_recursion;
-}
-
-#endif
-
static void nf_do_netdev_egress(struct sk_buff *skb, struct net_device *dev,
enum nf_dev_hooks hook)
{
diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
index 152a9fb4d23a..492bb599a499 100644
--- a/net/netfilter/nft_fwd_netdev.c
+++ b/net/netfilter/nft_fwd_netdev.c
@@ -141,13 +141,20 @@ static void nft_fwd_neigh_eval(const struct nft_expr *expr,
goto out;
}
+ if (*nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT) {
+ verdict = NF_DROP;
+ goto out;
+ }
+
dev = dev_get_by_index_rcu(nft_net(pkt), oif);
if (dev == NULL)
return;
skb->dev = dev;
skb_clear_tstamp(skb);
+ (*nf_get_nf_dup_skb_recursion())++;
neigh_xmit(neigh_table, dev, addr, skb);
+ (*nf_get_nf_dup_skb_recursion())--;
out:
regs->verdict.code = verdict;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] gre: Count GRE packet drops
From: Gal Pressman @ 2026-04-09 10:52 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, netdev
Cc: David Ahern, Simon Horman, Dragos Tatulea, Nimrod Oren
In-Reply-To: <20260409090945.1542440-1-gal@nvidia.com>
Addressing Sashiko's comments:
https://sashiko.dev/#/patchset/20260409090945.1542440-1-gal@nvidia.com
On 09/04/2026 12:09, Gal Pressman wrote:
> GRE is silently dropping packets without updating statistics.
>
> In case of drop, increment rx_dropped counter to provide visibility into
> packet loss. For the case where no GRE protocol handler is registered,
> use rx_nohandler.
>
> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
> Reviewed-by: Nimrod Oren <noren@nvidia.com>
> Signed-off-by: Gal Pressman <gal@nvidia.com>
> ---
> net/ipv4/gre_demux.c | 8 ++++++--
> net/ipv4/ip_gre.c | 1 +
> net/ipv6/ip6_gre.c | 1 +
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
> index dafd68f3436a..96fd7dc6d82d 100644
> --- a/net/ipv4/gre_demux.c
> +++ b/net/ipv4/gre_demux.c
> @@ -159,14 +159,18 @@ static int gre_rcv(struct sk_buff *skb)
> rcu_read_lock();
> proto = rcu_dereference(gre_proto[ver]);
> if (!proto || !proto->handler)
> - goto drop_unlock;
> + goto drop_nohandler;
> ret = proto->handler(skb);
> rcu_read_unlock();
> return ret;
>
> -drop_unlock:
> +drop_nohandler:
> rcu_read_unlock();
> + dev_core_stats_rx_nohandler_inc(skb->dev);
> + kfree_skb(skb);
> + return NET_RX_DROP;
> drop:
> + dev_core_stats_rx_dropped_inc(skb->dev);
---
At this point in gre_rcv(), does skb->dev point to the underlying
ingress physical interface (e.g., eth0) rather than a GRE tunnel device?
If so, does incrementing the L2 physical device counters for an L4 protocol
error case pollute the physical interface metrics? Unconfigured
GRE traffic from the network might cause physical device drop counters to
spike, which could be misdiagnosed as hardware issues.
Would it be better to expose these via protocol-specific MIB counters or by
passing a specific drop reason to kfree_skb_reason()?
---
Yes, it points to the underlying device, and that makes sense IMO.
At this point, the packets are still not associated with any tunnel (it
might not even exist).
> kfree_skb(skb);
> return NET_RX_DROP;
> }
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index dafcc0dcd77a..63fc8556b475 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -593,6 +593,7 @@ static int gre_rcv(struct sk_buff *skb)
> out:
> icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_PORT_UNREACH, 0);
> drop:
> + dev_core_stats_rx_dropped_inc(skb->dev);
> kfree_skb(skb);
> return 0;
> }
---
Does this fully account for silent packet drops during decapsulation?
Looking at erspan_rcv() and ipgre_rcv() which are called earlier in this
function, if they fail internally (for example, if __iptunnel_pull_header()
fails), they free the skb and return PACKET_RCVD:
net/ipv4/ip_gre.c:erspan_rcv() {
...
if (__iptunnel_pull_header(skb, len, htons(ETH_P_TEB), false, false)
< 0)
goto drop;
...
drop:
kfree_skb(skb);
return PACKET_RCVD;
}
Since gre_rcv() checks for PACKET_RCVD and returns 0:
if (erspan_rcv(skb, &tpi, hdr_len) == PACKET_RCVD)
return 0;
Does this bypass the newly added dev_core_stats_rx_dropped_inc() call under
the drop label entirely, leaving these packets silently dropped?
---
These are also silent drops, but these should be counted towards the
tunnel device, maybe as a separate patch.
^ permalink raw reply
* RE: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Biju Das @ 2026-04-09 10:52 UTC (permalink / raw)
To: Russell King
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <add_krK3MC1-SSsV@shell.armlinux.org.uk>
Hi Russell King,
Thanks for the feedback.
> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 09 April 2026 11:30
> Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
>
> On Thu, Apr 09, 2026 at 10:13:10AM +0000, Biju Das wrote:
> > Hi Ovidu,
> >
> > Thanks for the patch.
> >
> > > -----Original Message-----
> > > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > Sent: 09 April 2026 10:57
> > > Subject: [PATCH net v2 2/2] net: phy: micrel: remove
> > > ksz9131_resume()
> > >
> > > ksz9131_resume() was added to restore RGMII delays on resume for
> > > platforms where the PHY loses power during suspend to RAM. However, for s2idle, the PHY stays in
> Software Power-Down (SPD) during resume.
> > > In that case,
> > > ksz9131_config_rgmii_delay() accesses MMD registers before
> > > kszphy_resume() clears BMCR_PDOWN. The
> > > KSZ9131 datasheet states that during SPD, access to the MMD registers is restricted:
> > >
> > > - Only access to the standard registers (0 through 31) is supported.
> > > - Access to MMD address spaces other than MMD address space 1 is
> > > possible if the spd_clock_gate_override bit is set.
> > > - Access to MMD address space 1 is not possible.
> > >
> > > Additionally, only RGMII delays were restored, while other settings
> > > from ksz9131_config_init() were not.
> > >
> > > Now that the preceding commit ("net: phylink: call phy_init_hw() in
> > > phylink resume path") performs a
> > > phy_init_hw() during phylink resume,
> > > ksz9131_resume() is no longer needed.
> > >
> > > Remove it and use kszphy_resume() directly.
> >
> > How to avoid code duplication in this case?
> >
> > For eg: phy_init_hw() makes the phy out of SPD state
> >
> > and kszphy_resume() unconditionally makes the phy out of SPD state again.
> > ¬ kszphy_generic_resume
> > ¬ genphy_resume
>
> My question would be... if we mandate that phy_init_hw() must be called before phy_resume() by MAC
> drivers, then how much of kszphy_resume() becomes redundant?
>
> Given that populating drv->soft_reset() with genphy_soft_reset() means the PDOWN bit will be cleared,
> genphy_resume() becomes redundant.
>
> phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
>
> It will also call drv->config_init(), which will call kszphy_config_reset().
>
> So most of kszphy_resume() becomes unnecessary. I think the only thing that remains would be the call
> to kszphy_enable_clk() - and is it fine to call that after phy_init_hw() ?
It just needs kszphy_enable_clk() and phydev->drv->config_intr() to enable PHY interrupts for
suspend-to-RAM to work on RZ/G3E SMARC EVK.
Cheers,
Biju
^ permalink raw reply
* [pull-request] mlx5-next updates 2026-04-09
From: Tariq Toukan @ 2026-04-09 11:04 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Leon Romanovsky, Jason Gunthorpe, Saeed Mahameed, Tariq Toukan,
Mark Bloch, Shay Drori, Parav Pandit, Joe Damato, Simon Horman,
linux-rdma, linux-kernel, netdev, Gal Pressman, Dragos Tatulea
Hi,
The following pull-request contains common mlx5 updates
for your *net-next* tree.
Please pull and let me know of any problem.
Regards,
Tariq
----------------------------------------------------------------
The following changes since commit 4dd2115f43594da5271a1aa34fde6719b4259047:
net/mlx5: Expose MLX5_UMR_ALIGN definition (2026-03-16 16:23:00 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-next
for you to fetch changes up to a1bac8b70ede332a05487081c7512d2947f3a912:
net/mlx5: Add icm_mng_function_id_mode cap bit (2026-04-09 05:26:39 -0400)
----------------------------------------------------------------
Moshe Shemesh (2):
net/mlx5: Rename MLX5_PF page counter type to MLX5_SELF
net/mlx5: Add icm_mng_function_id_mode cap bit
Parav Pandit (1):
mlx5: Remove redundant iseg base
Patrisious Haddad (1):
net/mlx5: Add vhca_id_type bit to alias context
drivers/infiniband/hw/mlx5/main.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 3 +--
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c | 3 +--
include/linux/mlx5/driver.h | 3 +--
include/linux/mlx5/mlx5_ifc.h | 15 ++++++++++++---
6 files changed, 18 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Russell King (Oracle) @ 2026-04-09 11:05 UTC (permalink / raw)
To: Biju Das
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY3PR01MB113465B215559404D0FBD04AE86582@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On Thu, Apr 09, 2026 at 10:52:35AM +0000, Biju Das wrote:
> Hi Russell King,
>
> Thanks for the feedback.
>
> > -----Original Message-----
> > From: Russell King <linux@armlinux.org.uk>
> > Sent: 09 April 2026 11:30
> > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
> >
> > phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
> >
> > It will also call drv->config_init(), which will call kszphy_config_reset().
> >
> > So most of kszphy_resume() becomes unnecessary. I think the only thing that remains would be the call
> > to kszphy_enable_clk() - and is it fine to call that after phy_init_hw() ?
>
> It just needs kszphy_enable_clk() and phydev->drv->config_intr() to enable PHY interrupts for
> suspend-to-RAM to work on RZ/G3E SMARC EVK.
I think you mean WoL rather than suspend-to-RAM, although I don't see
anything in micrel.c that hints that WoL is supported, so please explain
why and how the PHY interrupt impacts suspend-to-RAM.
Note that a particular interrupt should not wake the system unless
enable_irq_wake() has been called for that specific interrupt.
--
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 v2] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Pablo Neira Ayuso @ 2026-04-09 11:05 UTC (permalink / raw)
To: Weiming Shi
Cc: Florian Westphal, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <20260409104911.722698-2-bestswngs@gmail.com>
On Thu, Apr 09, 2026 at 06:49:12PM +0800, Weiming Shi wrote:
> nft_fwd_neigh can be used in egress chains (NF_NETDEV_EGRESS). When the
> forwarding rule targets the same device or two devices forward to each
> other, neigh_xmit() triggers dev_queue_xmit() which re-enters
> nf_hook_egress(), causing infinite recursion and stack overflow.
>
> Move the nf_get_nf_dup_skb_recursion() accessor and NF_RECURSION_LIMIT
> to the shared header nf_dup_netdev.h as a static inline, so that
> nft_fwd_netdev can use the recursion counter directly without exported
> function call overhead. Guard neigh_xmit() with the same recursion
> limit already used in nf_do_netdev_egress().
>
> Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
I would just restrict this "feature", I don't see a point in allowing
this from egress?
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> include/net/netfilter/nf_dup_netdev.h | 13 +++++++++++++
> net/netfilter/nf_dup_netdev.c | 16 ----------------
> net/netfilter/nft_fwd_netdev.c | 7 +++++++
> 3 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
> index b175d271aec9..609bcf422a9b 100644
> --- a/include/net/netfilter/nf_dup_netdev.h
> +++ b/include/net/netfilter/nf_dup_netdev.h
> @@ -3,10 +3,23 @@
> #define _NF_DUP_NETDEV_H_
>
> #include <net/netfilter/nf_tables.h>
> +#include <linux/netdevice.h>
> +#include <linux/sched.h>
>
> void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
>
> +#define NF_RECURSION_LIMIT 2
> +
> +static inline u8 *nf_get_nf_dup_skb_recursion(void)
> +{
> +#ifndef CONFIG_PREEMPT_RT
> + return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
> +#else
> + return ¤t->net_xmit.nf_dup_skb_recursion;
> +#endif
> +}
> +
> struct nft_offload_ctx;
> struct nft_flow_rule;
>
> diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
> index fab8b9011098..a958a1b0c5be 100644
> --- a/net/netfilter/nf_dup_netdev.c
> +++ b/net/netfilter/nf_dup_netdev.c
> @@ -13,22 +13,6 @@
> #include <net/netfilter/nf_tables_offload.h>
> #include <net/netfilter/nf_dup_netdev.h>
>
> -#define NF_RECURSION_LIMIT 2
> -
> -#ifndef CONFIG_PREEMPT_RT
> -static u8 *nf_get_nf_dup_skb_recursion(void)
> -{
> - return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
> -}
> -#else
> -
> -static u8 *nf_get_nf_dup_skb_recursion(void)
> -{
> - return ¤t->net_xmit.nf_dup_skb_recursion;
> -}
> -
> -#endif
> -
> static void nf_do_netdev_egress(struct sk_buff *skb, struct net_device *dev,
> enum nf_dev_hooks hook)
> {
> diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
> index 152a9fb4d23a..492bb599a499 100644
> --- a/net/netfilter/nft_fwd_netdev.c
> +++ b/net/netfilter/nft_fwd_netdev.c
> @@ -141,13 +141,20 @@ static void nft_fwd_neigh_eval(const struct nft_expr *expr,
> goto out;
> }
>
> + if (*nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT) {
> + verdict = NF_DROP;
> + goto out;
> + }
> +
> dev = dev_get_by_index_rcu(nft_net(pkt), oif);
> if (dev == NULL)
> return;
>
> skb->dev = dev;
> skb_clear_tstamp(skb);
> + (*nf_get_nf_dup_skb_recursion())++;
> neigh_xmit(neigh_table, dev, addr, skb);
> + (*nf_get_nf_dup_skb_recursion())--;
> out:
> regs->verdict.code = verdict;
> }
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: possible deadlock in virtio_transport_release (vsock_register_mutex vs sk_lock)
From: Stefano Garzarella @ 2026-04-09 11:07 UTC (permalink / raw)
To: weibo Zhang; +Cc: davem, edumazet, kuba, pabeni, netdev, linux-kernel
In-Reply-To: <CADaZ31BntFddQpK8nnLtGccyKA-kw-usOHZwEscA70+dgB2WSw@mail.gmail.com>
On Thu, 9 Apr 2026 at 11:06, weibo Zhang <weibozhang2050@gmail.com> wrote:
>
> Hi,
>
> I am reporting a possible circular locking dependency (AB-BA deadlock) in the
>
> vsock subsystem between vsock_register_mutex and sk_lock-AF_VSOCK, found by
>
> syzkaller-based kernel fuzzing on Linux 6.12.47.
>
> The deadlock is detected by lockdep and involves two lock ordering paths:
>
> Path #1 (bind path): sk_lock → vsock_register_mutex
>
> vsock_bind() → lock_sock(sk) → __vsock_bind() → vsock_find_cid()
>
> → vsock_registered_transport_cid() → mutex_lock(&vsock_register_mutex)
>
> Path #2 (connect + transport reassignment): vsock_register_mutex → sk_lock
>
> vsock_connect() → vsock_assign_transport()
>
> → mutex_lock(&vsock_register_mutex) [line 469, af_vsock.c]
>
> → old transport->release(vsk) [line 502, af_vsock.c]
>
> → virtio_transport_release()
>
> → virtio_transport_close()
>
> → virtio_transport_wait_close()
>
> → lock_sock(sk) [line 1207, virtio_transport_common.c]
>
> The second path is triggered when a socket that already has a transport
>
> assigned (e.g., loopback from a previous CID_LOCAL connect) attempts to
>
> connect to a different CID (e.g., CID_HOST), causing vsock_assign_transport()
>
> to release the old transport while holding vsock_register_mutex.
>
>
> A possible fix would be to drop vsock_register_mutex before calling
>
> transport->release() in vsock_assign_transport(), or to avoid calling
Which is exactly what we did with
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c877e7535260cc7a21484c994e8ce7e8cb6780
This was released with v6.18 and backported on stable branches.
>
> lock_sock() from within the transport release path when called from
>
> vsock_assign_transport().
>
> This can be reproduced on:
>
> HEAD commit: Linux 6.12.47
v6.12.56 should contain the backport of that patch, can you test it
(or a newer version)?
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] r8152: Add support for the RTL8157 hardware
From: Birger Koblitz @ 2026-04-09 11:18 UTC (permalink / raw)
To: Paolo Abeni, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <8b324f8c-f4f8-4e90-b5d6-9b87ec3daf2b@redhat.com>
On 09/04/2026 12:16, Paolo Abeni wrote:
> On 4/4/26 9:57 AM, Birger Koblitz wrote:
>> @@ -6534,8 +6842,11 @@ static void rtl8156_up(struct r8152 *tp)
>> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
>> PLA_MCU_SPDWN_EN);
>>
>> - ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
>> - RG_PWRDN_EN | ALL_SPEED_OFF);
>> + ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
>
> AI review notes that the above leads to 2 consecutive:
>
> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
>
> with slightly different formatting, likely C&P error?!?
>
> I think this is better handled with a follow-up, if needed, as I don't
> see any possible issue out of it.
>
> Other AI comments look not relevant.
Thanks a lot, Paolo!
I will follow up on this for sure, there is also the RTL8159...
I also contacted the Realtek devs, but have not heard back so far, probably needs
internal escalation...
Birger
^ permalink raw reply
* RE: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Biju Das @ 2026-04-09 11:19 UTC (permalink / raw)
To: Russell King
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <adeH5y5TiZdaK94d@shell.armlinux.org.uk>
Hi Russell King,
> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 09 April 2026 12:05
> Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
>
> On Thu, Apr 09, 2026 at 10:52:35AM +0000, Biju Das wrote:
> > Hi Russell King,
> >
> > Thanks for the feedback.
> >
> > > -----Original Message-----
> > > From: Russell King <linux@armlinux.org.uk>
> > > Sent: 09 April 2026 11:30
> > > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove
> > > ksz9131_resume()
> > >
> > > phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
> > >
> > > It will also call drv->config_init(), which will call kszphy_config_reset().
> > >
> > > So most of kszphy_resume() becomes unnecessary. I think the only
> > > thing that remains would be the call to kszphy_enable_clk() - and is it fine to call that after
> phy_init_hw() ?
> >
> > It just needs kszphy_enable_clk() and phydev->drv->config_intr() to
> > enable PHY interrupts for suspend-to-RAM to work on RZ/G3E SMARC EVK.
>
> I think you mean WoL rather than suspend-to-RAM, although I don't see anything in micrel.c that hints
> that WoL is supported, so please explain why and how the PHY interrupt impacts suspend-to-RAM.
This is not WoL. During Suspend-to-RAM, the DDR goes into retention mode while
the CPU, SoC, and PHY power is cut off.
During resume, TF-A detects WARM_RESET, brings DDR out of retention, and jumps to
the PSCI resume path.
>
> Note that a particular interrupt should not wake the system unless
> enable_irq_wake() has been called for that specific interrupt.
If PHY interrupts are not configured during resume, no link interrupt is received and the message:
"renesas-gbeth 11c30000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx"
is not seen, as shown in [1].
Cheers,
Biju
[1]
root@smarc-rzg3l:~# echo mem > /sys/power/state
[ 184.611719] PM: suspend entry (deep)
[ 184.616854] Filesystems sync: 0.000 seconds
[ 184.629390] Freezing user space processes
[ 184.637539] Freezing user space processes completed (elapsed 0.003 seconds)
[ 184.644541] OOM killer disabled.
[ 184.647758] Freezing remaining freezable tasks
[ 184.653520] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[ 184.660941] printk: Suspending console(s) (use no_console_suspend to debug)
NOTICE: BL2: v2.10.5(release):2.10.5/rz_soc_dev-383-g15a06c881
NOTICE: BL2: Built : 12:13:18, Apr 2 2026
INFO: BL2: Doing platform setup
INFO: Configuring TrustZone Controller
INFO: Total 3 regions set.
INFO: Configuring TrustZone Controller
INFO: Total 1 regions set.
INFO: Configuring TrustZone Controller
INFO: Total 1 regions set.
INFO: eMMC boot from partition 1
INFO: Loading image id=39 at address 0x44428
INFO: emmcdrv_block_len: len: 0x00001000
INFO: Load dst=0x44428 src=(p:1)0x260000(4864) len=0x1000(8)
INFO: Image id=39 loaded: 0x44428 - 0x45428
INFO: DDR: Retention Exit (Rev. 02.05)
NOTICE: BL2: SYS_LSI_MODE: 0x12051
NOTICE: BL2: SYS_LSI_DEVID: 0x87d9447
INFO: BL2: Skip loading image id 3
INFO: BL2: Skip loading image id 5
NOTICE: BL2: Booting BL31
INFO: Entry point address = 0x44000000
INFO: SPSR = 0x3cd
[ 184.670380] renesas-gbeth 11c30000.ethernet end0: Link is Down
[ 184.674006] Disabling non-boot CPUs ...
[ 184.675870] psci: CPU3 killed (polled 4 ms)
[ 184.679357] psci: CPU2 killed (polled 0 ms)
[ 184.683525] psci: CPU1 killed (polled 0 ms)
[ 184.685755] Enabling non-boot CPUs ...
[ 184.686014] Detected VIPT I-cache on CPU1
[ 184.686070] GICv3: CPU1: found redistributor 100 region 0:0x0000000012460000
[ 184.686119] CPU1: Booted secondary processor 0x0000000100 [0x412fd050]
[ 184.687190] CPU1 is up
[ 184.687348] Detected VIPT I-cache on CPU2
[ 184.687384] GICv3: CPU2: found redistributor 200 region 0:0x0000000012480000
[ 184.687419] CPU2: Booted secondary processor 0x0000000200 [0x412fd050]
[ 184.688357] CPU2 is up
[ 184.688534] Detected VIPT I-cache on CPU3
[ 184.688573] GICv3: CPU3: found redistributor 300 region 0:0x00000000124a0000
[ 184.688615] CPU3: Booted secondary processor 0x0000000300 [0x412fd050]
[ 184.689702] CPU3 is up
[ 184.692965] da7213 3-001a: Unable to sync registers 0x23-0x23. -6
[ 184.767008] dwmac4: Master AXI performs fixed burst length
[ 184.767049] renesas-gbeth 11c30000.ethernet end0: No Safety Features support found
[ 184.767090] renesas-gbeth 11c30000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported
[ 184.769791] renesas-gbeth 11c30000.ethernet end0: configuring for phy/rgmii-id link mode
[ 184.839754] dwmac4: Master AXI performs fixed burst length
[ 184.839784] renesas-gbeth 11c40000.ethernet end1: No Safety Features support found
[ 184.839814] renesas-gbeth 11c40000.ethernet end1: IEEE 1588-2008 Advanced Timestamp supported
[ 184.840892] renesas-gbeth 11c40000.ethernet end1: configuring for phy/rgmii-id link mode
[ 184.994774] OOM killer enabled.
[ 184.997922] Restarting tasks: Starting
[ 185.002227] Restarting tasks: Done
[ 185.005781] random: crng reseeded on system resumption
[ 185.011124] PM: suspend exit
root@smarc-rzg3l:~#
root@smarc-rzg3l:~# [ 187.356951] renesas-gbeth 11c30000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx
^ permalink raw reply
* Re: [PATCH v2] netfilter: nft_fwd_netdev: use recursion counter in neigh egress path
From: Pablo Neira Ayuso @ 2026-04-09 11:21 UTC (permalink / raw)
To: Weiming Shi
Cc: Florian Westphal, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <adeIF7ZsJsZsgwQy@chamomile>
On Thu, Apr 09, 2026 at 01:06:03PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Apr 09, 2026 at 06:49:12PM +0800, Weiming Shi wrote:
> > nft_fwd_neigh can be used in egress chains (NF_NETDEV_EGRESS). When the
> > forwarding rule targets the same device or two devices forward to each
> > other, neigh_xmit() triggers dev_queue_xmit() which re-enters
> > nf_hook_egress(), causing infinite recursion and stack overflow.
> >
> > Move the nf_get_nf_dup_skb_recursion() accessor and NF_RECURSION_LIMIT
> > to the shared header nf_dup_netdev.h as a static inline, so that
> > nft_fwd_netdev can use the recursion counter directly without exported
> > function call overhead. Guard neigh_xmit() with the same recursion
> > limit already used in nf_do_netdev_egress().
> >
> > Fixes: f87b9464d152 ("netfilter: nft_fwd_netdev: Support egress hook")
>
> I would just restrict this "feature", I don't see a point in allowing
> this from egress?
Hm, actually this can be combined with if0 device, fixing it makes sense.
> > Reported-by: Xiang Mei <xmei5@asu.edu>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> > ---
> > include/net/netfilter/nf_dup_netdev.h | 13 +++++++++++++
> > net/netfilter/nf_dup_netdev.c | 16 ----------------
> > net/netfilter/nft_fwd_netdev.c | 7 +++++++
> > 3 files changed, 20 insertions(+), 16 deletions(-)
> >
> > diff --git a/include/net/netfilter/nf_dup_netdev.h b/include/net/netfilter/nf_dup_netdev.h
> > index b175d271aec9..609bcf422a9b 100644
> > --- a/include/net/netfilter/nf_dup_netdev.h
> > +++ b/include/net/netfilter/nf_dup_netdev.h
> > @@ -3,10 +3,23 @@
> > #define _NF_DUP_NETDEV_H_
> >
> > #include <net/netfilter/nf_tables.h>
> > +#include <linux/netdevice.h>
> > +#include <linux/sched.h>
> >
> > void nf_dup_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> > void nf_fwd_netdev_egress(const struct nft_pktinfo *pkt, int oif);
> >
> > +#define NF_RECURSION_LIMIT 2
> > +
> > +static inline u8 *nf_get_nf_dup_skb_recursion(void)
> > +{
> > +#ifndef CONFIG_PREEMPT_RT
> > + return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
> > +#else
> > + return ¤t->net_xmit.nf_dup_skb_recursion;
> > +#endif
> > +}
> > +
> > struct nft_offload_ctx;
> > struct nft_flow_rule;
> >
> > diff --git a/net/netfilter/nf_dup_netdev.c b/net/netfilter/nf_dup_netdev.c
> > index fab8b9011098..a958a1b0c5be 100644
> > --- a/net/netfilter/nf_dup_netdev.c
> > +++ b/net/netfilter/nf_dup_netdev.c
> > @@ -13,22 +13,6 @@
> > #include <net/netfilter/nf_tables_offload.h>
> > #include <net/netfilter/nf_dup_netdev.h>
> >
> > -#define NF_RECURSION_LIMIT 2
> > -
> > -#ifndef CONFIG_PREEMPT_RT
> > -static u8 *nf_get_nf_dup_skb_recursion(void)
> > -{
> > - return this_cpu_ptr(&softnet_data.xmit.nf_dup_skb_recursion);
> > -}
> > -#else
> > -
> > -static u8 *nf_get_nf_dup_skb_recursion(void)
> > -{
> > - return ¤t->net_xmit.nf_dup_skb_recursion;
> > -}
> > -
> > -#endif
> > -
> > static void nf_do_netdev_egress(struct sk_buff *skb, struct net_device *dev,
> > enum nf_dev_hooks hook)
> > {
> > diff --git a/net/netfilter/nft_fwd_netdev.c b/net/netfilter/nft_fwd_netdev.c
> > index 152a9fb4d23a..492bb599a499 100644
> > --- a/net/netfilter/nft_fwd_netdev.c
> > +++ b/net/netfilter/nft_fwd_netdev.c
> > @@ -141,13 +141,20 @@ static void nft_fwd_neigh_eval(const struct nft_expr *expr,
> > goto out;
> > }
> >
> > + if (*nf_get_nf_dup_skb_recursion() > NF_RECURSION_LIMIT) {
> > + verdict = NF_DROP;
> > + goto out;
> > + }
> > +
> > dev = dev_get_by_index_rcu(nft_net(pkt), oif);
> > if (dev == NULL)
> > return;
> >
> > skb->dev = dev;
> > skb_clear_tstamp(skb);
> > + (*nf_get_nf_dup_skb_recursion())++;
> > neigh_xmit(neigh_table, dev, addr, skb);
> > + (*nf_get_nf_dup_skb_recursion())--;
> > out:
> > regs->verdict.code = verdict;
> > }
> > --
> > 2.43.0
> >
> >
^ permalink raw reply
* RE: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825
From: Nitka, Grzegorz @ 2026-04-09 11:21 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, Oros, Petr,
richardcochran@gmail.com, andrew+netdev@lunn.ch,
Kitszel, Przemyslaw, Nguyen, Anthony L,
Prathosh.Satish@microchip.com, Vecera, Ivan, jiri@resnulli.us,
Kubalewski, Arkadiusz, vadim.fedorenko@linux.dev,
donald.hunter@gmail.com, horms@kernel.org, pabeni@redhat.com,
davem@davemloft.net, edumazet@google.com
In-Reply-To: <20260406192312.0f7a2760@kernel.org>
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Tuesday, April 7, 2026 4:23 AM
> To: Nitka, Grzegorz <grzegorz.nitka@intel.com>
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org; Oros, Petr <poros@redhat.com>;
> richardcochran@gmail.com; andrew+netdev@lunn.ch; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Prathosh.Satish@microchip.com; Vecera,
> Ivan <ivecera@redhat.com>; jiri@resnulli.us; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@intel.com>; vadim.fedorenko@linux.dev;
> donald.hunter@gmail.com; horms@kernel.org; pabeni@redhat.com;
> davem@davemloft.net; edumazet@google.com
> Subject: Re: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX
> reference clock control for E825
>
> On Fri, 3 Apr 2026 01:06:18 +0200 Grzegorz Nitka wrote:
> > This series adds TX reference clock support for E825 devices and exposes
> > TX clock selection and synchronization status via the Linux DPLL
> > subsystem.
> > E825 hardware contains a dedicated Tx clock (TXC) domain that is
> > distinct
> > from PPS and EEC. TX reference clock selection is device‑wide, shared
> > across ports, and mediated by firmware as part of the link bring‑up
> > process. As a result, TX clock selection intent may differ from the
> > effective hardware configuration, and software must verify the outcome
> > after link‑up.
> > To support this, the series introduces TXC support incrementally across
> > the DPLL core and the ice driver:
> >
> > - add a new DPLL type (TXC) to represent transmit clock generators;
>
> I'm not grasping why this is needed, isn't it part of any EEC system
> that the DPLL can drive the TXC? Is your system going to expose multiple
> DPLLs now for one NIC?
>
Hello Jakub,
For E825 device, the short answer is yes. We have platform EEC now and
we want to add:
- TXC DPLLs per port, and
- PPS DPLL for TSPLL config purposes (in the near future)
EEC (Ethernet Equipment Clock) type DPLL is designed to control multiple
source signals (internal-NIC or external), where one drives the dpll device,
where multiple outputs are possible, each could drive various components
as well as propagate signal to external devices.
TXC is specific dpll device that associated with single ETH port to control it's source,
there is no need to declare any outputs as the single output is already determined.
Basically, having TXC DPLL indicates per port control over SyncE (or some external)
clock source.
> > - relax DPLL pin registration rules for firmware‑described shared pins
> > and extend pin notifications with a source identifier;
> > - allow dynamic state control of SyncE reference pins where hardware
> > supports it;
> > - add CPI infrastructure for PHY‑side TX clock control on E825C;
> > - introduce a TXC DPLL device and TX reference clock pins (EXT_EREF0 and
> > SYNCE) in the ice driver;
> > - extend the Restart Auto‑Negotiation command to carry a TX reference
> > clock index;
> > - implement hardware‑backed TX reference clock switching, post‑link
> > - verification, and TX synchronization reporting.
> >
> > TXCLK pins report TX reference topology only. Actual synchronization
> > success is reported via the TXC DPLL lock status, which is updated after
> > hardware verification: external Tx references report LOCKED, while the
> > internal ENET/TXCO source reports UNLOCKED.
> > This provides reliable TX reference selection and observability on E825
> > devices using standard DPLL interfaces, without conflating user intent
> > with effective hardware behavior.
^ permalink raw reply
* Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Russell King (Oracle) @ 2026-04-09 11:30 UTC (permalink / raw)
To: Biju Das
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY3PR01MB11346732465160FFE9DCAADD686582@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On Thu, Apr 09, 2026 at 11:19:43AM +0000, Biju Das wrote:
> Hi Russell King,
>
> > -----Original Message-----
> > From: Russell King <linux@armlinux.org.uk>
> > Sent: 09 April 2026 12:05
> > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
> >
> > On Thu, Apr 09, 2026 at 10:52:35AM +0000, Biju Das wrote:
> > > Hi Russell King,
> > >
> > > Thanks for the feedback.
> > >
> > > > -----Original Message-----
> > > > From: Russell King <linux@armlinux.org.uk>
> > > > Sent: 09 April 2026 11:30
> > > > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove
> > > > ksz9131_resume()
> > > >
> > > > phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
> > > >
> > > > It will also call drv->config_init(), which will call kszphy_config_reset().
> > > >
> > > > So most of kszphy_resume() becomes unnecessary. I think the only
> > > > thing that remains would be the call to kszphy_enable_clk() - and is it fine to call that after
> > phy_init_hw() ?
> > >
> > > It just needs kszphy_enable_clk() and phydev->drv->config_intr() to
> > > enable PHY interrupts for suspend-to-RAM to work on RZ/G3E SMARC EVK.
> >
> > I think you mean WoL rather than suspend-to-RAM, although I don't see anything in micrel.c that hints
> > that WoL is supported, so please explain why and how the PHY interrupt impacts suspend-to-RAM.
>
> This is not WoL. During Suspend-to-RAM, the DDR goes into retention mode while
> the CPU, SoC, and PHY power is cut off.
>
> During resume, TF-A detects WARM_RESET, brings DDR out of retention, and jumps to
> the PSCI resume path.
>
> >
> > Note that a particular interrupt should not wake the system unless
> > enable_irq_wake() has been called for that specific interrupt.
>
> If PHY interrupts are not configured during resume, no link interrupt is received and the message:
> "renesas-gbeth 11c30000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx"
> is not seen, as shown in [1].
... and why does that happen? Is it because the PHY has lost its
interrupt configuration and that needs to be reprogrammed?
If you don't disable the PHY interrupt in the suspend path, then
will the call to drv->config_intr() via phy_init_hw() before
phy_resume() be sufficient?
--
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] l2tp: take a session reference in pppol2tp_ioctl()
From: Paolo Abeni @ 2026-04-09 11:41 UTC (permalink / raw)
To: Yiqi Sun, jchapman; +Cc: davem, edumazet, kuba, horms, netdev
In-Reply-To: <20260404133245.2391409-1-sunyiqixm@gmail.com>
On 4/4/26 3:32 PM, Yiqi Sun wrote:
> pppol2tp_ioctl() reads sock->sk->sk_user_data and dereferences the
> returned l2tp_session without taking a reference on it.
>
> Since the ppp socket/session lifetime rework, session teardown runs
> asynchronously and can clear sk_user_data and drop the last session
> reference in parallel with ioctl(). This leaves ioctl() with a stale
> session pointer and can trigger a use-after-free.
It's not immediately obvious to me which are the actual code paths
involved, please include a more accurate description of the relevant race.
>
> Fix this by using pppol2tp_sock_to_session() in pppol2tp_ioctl() and
> dropping the session reference before returning. This matches the
> existing getsockopt/setsockopt paths.
>
> Fixes: c5cbaef992d64 ("l2tp: refactor ppp socket/session relationship")
> Signed-off-by: Yiqi Sun <sunyiqixm@gmail.com>
> ---
> net/l2tp/l2tp_ppp.c | 88 +++++++++++++++++++++++++++------------------
> 1 file changed, 54 insertions(+), 34 deletions(-)
>
> diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
> index ae4543d5597b..e6d7d3537180 100644
> --- a/net/l2tp/l2tp_ppp.c
> +++ b/net/l2tp/l2tp_ppp.c
> @@ -1042,66 +1042,79 @@ static int pppol2tp_tunnel_copy_stats(struct pppol2tp_ioc_stats *stats,
> static int pppol2tp_ioctl(struct socket *sock, unsigned int cmd,
> unsigned long arg)
> {
> + struct sock *sk = sock->sk;
> struct pppol2tp_ioc_stats stats;
> struct l2tp_session *session;
> + int err;
> +
> + err = -ENOTCONN;
> + if (!sk->sk_user_data)
> + goto end;
> +
> + err = -EBADF;
> + session = pppol2tp_sock_to_session(sk);
> + if (!session)
> + goto end;
Consolidating the checks here brings an user visible change, as
unsupported cmds previously delivered -ENOIOCTLCMD.
>
> switch (cmd) {
> case PPPIOCGMRU:
> case PPPIOCGFLAGS:
> - session = sock->sk->sk_user_data;
> - if (!session)
> - return -ENOTCONN;
> -
> if (WARN_ON(session->magic != L2TP_SESSION_MAGIC))
This check is already present in pppol2tp_sock_to_session()
Similar chunks below.
/P
^ permalink raw reply
* Re: [PATCH net v3 0/5] bonding: 3ad: fix carrier state with no valid slaves
From: Louis Scalbert @ 2026-04-09 11:49 UTC (permalink / raw)
To: Jonas Gorski
Cc: Jakub Kicinski, netdev, andrew+netdev, jv, edumazet, pabeni, fbl,
andy, shemminger, maheshb
In-Reply-To: <6631e1e7-8728-46a4-9999-ea9910a1abfb@gmail.com>
Hello,
Le jeu. 9 avr. 2026 à 08:53, Jonas Gorski <jonas.gorski@gmail.com> a écrit :
>
> On 09/04/2026 05:13, Jakub Kicinski wrote:
> > On Wed, 8 Apr 2026 17:23:48 +0200 Louis Scalbert wrote:
> >> The current behavior is not compliant with the LACP standard. This
> >> patchset introduces a working behavior that is not strictly
> >> standard-compliant either, but is widely adopted across the industry.
> >> It consists of bringing the bonding master interface down to signal to
> >> upper-layer processes that it is not usable.
> >
> > Is the only problem the compliance? If so I don't think this qualifies
> > as a fix. Please drop the Fixes tags and repost for net-next. Please
> > keep in mind the 24h reposting period (also I need some time tomorrow
> > to queue your patch to the CI so that the selftest passes when v4 is
> > posted :()
The problem is not only about compliance.
In his review of v2, Jay argued that the current behavior is
standard-compliant and pointed out that it enables some use cases, such
as PXE facing an LACP bond.
I replied that the current implementation is not actually compliant
with the standard, and that the PXE case does not truly work in a
reliable way, since success depends on a random link choice.
My goal is not to make the PXE use case work. Rather, this series fixes
other problematic scenarios. To avoid regressing setups that may
benefit from the current behavior, I added a configuration knob that
allows preserving the legacy behavior. The legacy mode should be
deprecated in my opinion.
>
> Signalling link up too early can cause issues for some protocols that
> may change behavior in the absence of PDUs from a link partner.
I agree with your point. I have observed issues with
keepalived VRRP when it is configured on top of a bonding interface.
When the bond reports carrier as up while no slave is actually able to
receive traffic (due to the partner not being ready, as indicated by the
absence of LACP negotiation), the VRRP process interprets the interface
as operational. At the same time, the absence of received VRRP
advertisements is interpreted as if it were the only router on the
segment. As a result, it transitions to the MASTER state.
In reality, another VRRP router may already be MASTER and actively
sending advertisements, but those packets are not received due to the
bonding state. This leads to a split-brain condition with multiple
masters on the network.
Such a situation breaks the assumptions of
VRRP, where a single MASTER is expected to handle traffic,
and can result in traffic inconsistency or loss when upper-layer
processes rely on this behavior.
>
> E.g. AFAIU RSTP may decide the bond is an edge port because no RSTP
> BPDUs received and put the bond in forwarding, which then temporarily
> creates a loop once the bond actually starts forwarding packets (until
> it receives the next RSTP BPDU, which may take up to two seconds).
>
There are also situations where BGP incorrectly assumes that the link is
usable while it is not.
Please confirm whether it should be a fix or not.
> Best regards,
> Jonas
Best regards,
Louis Scalbert
^ permalink raw reply
* Re: [PATCH net-next] selftests: net: py: add test case filtering and listing
From: Gal Pressman @ 2026-04-09 11:50 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, shuah, petrm,
willemb, linux-kselftest
In-Reply-To: <20260407151715.3800579-1-kuba@kernel.org>
On 07/04/2026 18:17, Jakub Kicinski wrote:
> When developing new test cases and reproducing failures in
> existing ones we currently have to run the entire test which
> can take minutes to finish.
>
> Add command line options for test selection, modeled after
> kselftest_harness.h:
>
> -l list tests (all or filtered)
> -t name include test
> -T name exclude test
>
> Since we don't have as clean separation into fixture / variant /
> test as kselftest_harness this is not really a 1 to 1 match.
> We have to lean on glob patterns instead.
>
> Like in kselftest_harness filters are evaluated in order, first
> match wins. If only exclusions are specified everything else is
> included and vice versa.
>
> Glob patterns (*, ?, [) are supported in addition to exact
> matching.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This is very useful!
Tested-by: Gal Pressman <gal@nvidia.com>
^ permalink raw reply
* [PATCH net-next 0/7] net/mlx5: Improve representor lifecycle and fix work queue deadlock
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
Hi,
See detailed description by Mark below [1].
Regards,
Tariq
[1]
This series addresses three problems that have been present for years.
First, there is no coordination between E-Switch reconfiguration and
representor registration. The E-Switch can be mid-way through a mode
change or VF count update while mlx5_ib walks in and registers or
unregisters representors. Nothing stops them. The race window is small
and there is no field report, but it is clearly wrong.
A mutex is not the answer. The representor callbacks reach into RDMA,
netdev, and LAG layers that already hold their own locks, making a
new mutex in the E-Switch layer a deadlock waiting to happen.
Second, the E-Switch work queue has a deadlock of its own.
mlx5_eswitch_cleanup() drains the work queue while holding the devlink
lock. Workers on that queue acquire devlink lock before checking whether
their work is still relevant. They block. The cleanup path waits for
them to finish. Deadlock.
Third, loading mlx5_ib while the device is already in switchdev mode
does not bring up the IB representors. This has been broken for years.
mlx5_eswitch_register_vport_reps() only stores callbacks; nobody
triggers the actual load after registration.
For the work queue deadlock: introduce a generation counter in the
top-level mlx5_eswitch struct (moved from mlx5_esw_functions,
which only covered function-change events) and a generic dispatch helper
mlx5_esw_add_work(). The worker esw_wq_handler() checks the counter
before touching the devlink lock using devl_trylock() in a loop. Stale
work exits immediately without ever contending. The counter is
incremented at every E-Switch operation boundary: cleanup, disable,
mode-set, enable, disable_sriov.
For the registration race: a simple atomic block state guards all
reconfiguration paths. mlx5_esw_reps_block()/mlx5_esw_reps_unblock()
spin a cmpxchg between UNBLOCKED and BLOCKED. Every reconfiguration
path (mode set, enable, disable, VF/SF add/del, LAG reload, and the
register/unregister calls themselves) brackets its work with this guard.
No new locks, no deadlock risk.
For the missing IB representors: now that the work queue infrastructure
is in place, mlx5_eswitch_register_vport_reps() queues a work item that
acquires the devlink lock and loads all relevant representors. This is
the change that actually fixes the long-standing bug.
One thing worth calling out: the block guard is non-reentrant. A caller
that tries to transition UNBLOCKED->BLOCKED while the E-Switch is already
BLOCKED will spin forever. All call sites were audited:
- mlx5_eswitch_enable/disable/disable_sriov hold BLOCKED only around
low-level vport helpers that do not call register/unregister.
- Inside mlx5_eswitch_unregister_vport_reps the unload callbacks run
while BLOCKED is held. The one callback that calls unregister
(mlx5_ib_vport_rep_unload in LAG shared-FDB mode) only does so on
peer E-Switch instances, each with its own independent atomic.
- mlx5_devlink_eswitch_mode_set acquires BLOCKED, then calls
esw_offloads_start/stop -> esw_mode_change. esw_mode_change releases
BLOCKED before calling rescan_drivers so that the probe/remove
callbacks that trigger register/unregister see UNBLOCKED.
esw_mode_change re-acquires before returning, and mode_set releases
at the end. This is an explicit hand-off of the guard across the
rescan window.
- mlx5_eswitch_register_vport_reps holds BLOCKED only while storing
callbacks and queuing the load work. The actual rep loading runs from
the work queue after the guard is released.
Patch 1 is cleanup. LAG and MPESW had the same representor reload
sequence duplicated in several places and the copies had started to
drift. This consolidates them into one helper.
Patches 2-4 fix the work queue deadlock in three steps: first move the
generation counter from mlx5_esw_functions to mlx5_eswitch;
then introduce the generic esw_wq_handler/mlx5_esw_add_work dispatch
infrastructure; then apply the actual fix by switching to devl_trylock
and adding generation increments at all operation boundaries.
Patch 5 adds the atomic block guard for representor registration,
protecting all reconfiguration paths.
Patch 6 moves the representor load triggered by
mlx5_eswitch_register_vport_reps() onto the work queue. This is the
patch that fixes IB representors not coming up when mlx5_ib is loaded
while the device is already in switchdev mode.
Patch 7 adds a driver profile that auto-enables switchdev at device
init, for deployments that always operate in switchdev mode and want
to avoid a manual devlink command after every probe.
Mark Bloch (7):
net/mlx5: Lag: refactor representor reload handling
net/mlx5: E-Switch, move work queue generation counter
net/mlx5: E-Switch, introduce generic work queue dispatch helper
net/mlx5: E-Switch, fix deadlock between devlink lock and esw->wq
net/mlx5: E-Switch, block representors during reconfiguration
net/mlx5: E-switch, load reps via work queue after registration
net/mlx5: Add profile to auto-enable switchdev mode at device init
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 25 ++-
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 15 +-
.../mellanox/mlx5/core/eswitch_offloads.c | 204 ++++++++++++++----
.../net/ethernet/mellanox/mlx5/core/lag/lag.c | 46 ++--
.../net/ethernet/mellanox/mlx5/core/lag/lag.h | 1 +
.../ethernet/mellanox/mlx5/core/lag/mpesw.c | 12 +-
.../net/ethernet/mellanox/mlx5/core/main.c | 26 ++-
.../ethernet/mellanox/mlx5/core/sf/devlink.c | 5 +
include/linux/mlx5/driver.h | 1 +
include/linux/mlx5/eswitch.h | 5 +
10 files changed, 267 insertions(+), 73 deletions(-)
base-commit: 9700282a7ec721e285771d995ccfe33845e776dc
--
2.44.0
^ permalink raw reply
* [PATCH net-next 1/7] net/mlx5: Lag: refactor representor reload handling
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
Representor reload during LAG/MPESW transitions has to be repeated in
several flows, and each open‑coded loop was easy to get out of sync
when adding new flags or tweaking error handling. Move the sequencing
into a single helper so that all call sites share the same ordering
and checks
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/lag/lag.c | 44 +++++++++++--------
.../net/ethernet/mellanox/mlx5/core/lag/lag.h | 1 +
.../ethernet/mellanox/mlx5/core/lag/mpesw.c | 12 ++---
3 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
index 449e4bd86c06..c402a8463081 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
@@ -1093,6 +1093,27 @@ void mlx5_lag_remove_devices(struct mlx5_lag *ldev)
}
}
+int mlx5_lag_reload_ib_reps(struct mlx5_lag *ldev, u32 flags)
+{
+ struct lag_func *pf;
+ int ret;
+ int i;
+
+ mlx5_ldev_for_each(i, 0, ldev) {
+ pf = mlx5_lag_pf(ldev, i);
+ if (!(pf->dev->priv.flags & flags)) {
+ struct mlx5_eswitch *esw;
+
+ esw = pf->dev->priv.eswitch;
+ ret = mlx5_eswitch_reload_ib_reps(esw);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
void mlx5_disable_lag(struct mlx5_lag *ldev)
{
bool shared_fdb = test_bit(MLX5_LAG_MODE_FLAG_SHARED_FDB, &ldev->mode_flags);
@@ -1130,9 +1151,7 @@ void mlx5_disable_lag(struct mlx5_lag *ldev)
mlx5_lag_add_devices(ldev);
if (shared_fdb)
- mlx5_ldev_for_each(i, 0, ldev)
- if (!(mlx5_lag_pf(ldev, i)->dev->priv.flags & MLX5_PRIV_FLAGS_DISABLE_ALL_ADEV))
- mlx5_eswitch_reload_ib_reps(mlx5_lag_pf(ldev, i)->dev->priv.eswitch);
+ mlx5_lag_reload_ib_reps(ldev, MLX5_PRIV_FLAGS_DISABLE_ALL_ADEV);
}
bool mlx5_lag_shared_fdb_supported(struct mlx5_lag *ldev)
@@ -1388,10 +1407,8 @@ static void mlx5_do_bond(struct mlx5_lag *ldev)
if (err) {
if (shared_fdb || roce_lag)
mlx5_lag_add_devices(ldev);
- if (shared_fdb) {
- mlx5_ldev_for_each(i, 0, ldev)
- mlx5_eswitch_reload_ib_reps(mlx5_lag_pf(ldev, i)->dev->priv.eswitch);
- }
+ if (shared_fdb)
+ mlx5_lag_reload_ib_reps(ldev, 0);
return;
}
@@ -1409,24 +1426,15 @@ static void mlx5_do_bond(struct mlx5_lag *ldev)
mlx5_nic_vport_enable_roce(dev);
}
} else if (shared_fdb) {
- int i;
-
dev0->priv.flags &= ~MLX5_PRIV_FLAGS_DISABLE_IB_ADEV;
mlx5_rescan_drivers_locked(dev0);
-
- mlx5_ldev_for_each(i, 0, ldev) {
- err = mlx5_eswitch_reload_ib_reps(mlx5_lag_pf(ldev, i)->dev->priv.eswitch);
- if (err)
- break;
- }
-
+ err = mlx5_lag_reload_ib_reps(ldev, 0);
if (err) {
dev0->priv.flags |= MLX5_PRIV_FLAGS_DISABLE_IB_ADEV;
mlx5_rescan_drivers_locked(dev0);
mlx5_deactivate_lag(ldev);
mlx5_lag_add_devices(ldev);
- mlx5_ldev_for_each(i, 0, ldev)
- mlx5_eswitch_reload_ib_reps(mlx5_lag_pf(ldev, i)->dev->priv.eswitch);
+ mlx5_lag_reload_ib_reps(ldev, 0);
mlx5_core_err(dev0, "Failed to enable lag\n");
return;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.h b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.h
index 6c911374f409..db561e306fc7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.h
@@ -199,4 +199,5 @@ int mlx5_get_next_ldev_func(struct mlx5_lag *ldev, int start_idx);
int mlx5_lag_get_dev_index_by_seq(struct mlx5_lag *ldev, int seq);
int mlx5_lag_num_devs(struct mlx5_lag *ldev);
int mlx5_lag_num_netdevs(struct mlx5_lag *ldev);
+int mlx5_lag_reload_ib_reps(struct mlx5_lag *ldev, u32 flags);
#endif /* __MLX5_LAG_H__ */
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c b/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c
index 5eea12a6887a..4d68e3092a56 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/mpesw.c
@@ -70,7 +70,6 @@ static int mlx5_lag_enable_mpesw(struct mlx5_lag *ldev)
int idx = mlx5_lag_get_dev_index_by_seq(ldev, MLX5_LAG_P1);
struct mlx5_core_dev *dev0;
int err;
- int i;
if (ldev->mode == MLX5_LAG_MODE_MPESW)
return 0;
@@ -103,11 +102,9 @@ static int mlx5_lag_enable_mpesw(struct mlx5_lag *ldev)
dev0->priv.flags &= ~MLX5_PRIV_FLAGS_DISABLE_IB_ADEV;
mlx5_rescan_drivers_locked(dev0);
- mlx5_ldev_for_each(i, 0, ldev) {
- err = mlx5_eswitch_reload_ib_reps(mlx5_lag_pf(ldev, i)->dev->priv.eswitch);
- if (err)
- goto err_rescan_drivers;
- }
+ err = mlx5_lag_reload_ib_reps(ldev, 0);
+ if (err)
+ goto err_rescan_drivers;
mlx5_lag_set_vports_agg_speed(ldev);
@@ -119,8 +116,7 @@ static int mlx5_lag_enable_mpesw(struct mlx5_lag *ldev)
mlx5_deactivate_lag(ldev);
err_add_devices:
mlx5_lag_add_devices(ldev);
- mlx5_ldev_for_each(i, 0, ldev)
- mlx5_eswitch_reload_ib_reps(mlx5_lag_pf(ldev, i)->dev->priv.eswitch);
+ mlx5_lag_reload_ib_reps(ldev, 0);
mlx5_mpesw_metadata_cleanup(ldev);
return err;
}
--
2.44.0
^ permalink raw reply related
* [PATCH net-next 2/7] net/mlx5: E-Switch, move work queue generation counter
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
The generation counter in mlx5_esw_functions is used to detect stale
work items on the E-Switch work queue. Move it from mlx5_esw_functions
to the top-level mlx5_eswitch struct so it can guard all work types,
not just function-change events.
This is a mechanical refactor: no behavioral change.
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 123c96716a54..1986d4d0e886 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1075,7 +1075,7 @@ static void mlx5_eswitch_event_handler_unregister(struct mlx5_eswitch *esw)
if (esw->mode == MLX5_ESWITCH_OFFLOADS &&
mlx5_eswitch_is_funcs_handler(esw->dev)) {
mlx5_eq_notifier_unregister(esw->dev, &esw->esw_funcs.nb);
- atomic_inc(&esw->esw_funcs.generation);
+ atomic_inc(&esw->generation);
}
}
@@ -2072,6 +2072,7 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
mutex_init(&esw->state_lock);
init_rwsem(&esw->mode_lock);
refcount_set(&esw->qos.refcnt, 0);
+ atomic_set(&esw->generation, 0);
esw->enabled_vports = 0;
esw->offloads.inline_mode = MLX5_INLINE_MODE_NONE;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
index 5128f5020dae..0c3d2bdebf8c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
@@ -340,7 +340,6 @@ struct mlx5_host_work {
struct mlx5_esw_functions {
struct mlx5_nb nb;
- atomic_t generation;
bool host_funcs_disabled;
u16 num_vfs;
u16 num_ec_vfs;
@@ -410,6 +409,7 @@ struct mlx5_eswitch {
struct mlx5_devcom_comp_dev *devcom;
u16 enabled_ipsec_vf_count;
bool eswitch_operation_in_progress;
+ atomic_t generation;
};
void esw_offloads_disable(struct mlx5_eswitch *esw);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index a078d06f4567..b2e7294d3a5c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -3667,7 +3667,7 @@ esw_vfs_changed_event_handler(struct mlx5_eswitch *esw, int work_gen,
devl_lock(devlink);
/* Stale work from one or more mode changes ago. Bail out. */
- if (work_gen != atomic_read(&esw->esw_funcs.generation))
+ if (work_gen != atomic_read(&esw->generation))
goto unlock;
new_num_vfs = MLX5_GET(query_esw_functions_out, out,
@@ -3729,7 +3729,7 @@ int mlx5_esw_funcs_changed_handler(struct notifier_block *nb, unsigned long type
esw = container_of(esw_funcs, struct mlx5_eswitch, esw_funcs);
host_work->esw = esw;
- host_work->work_gen = atomic_read(&esw_funcs->generation);
+ host_work->work_gen = atomic_read(&esw->generation);
INIT_WORK(&host_work->work, esw_functions_changed_event_handler);
queue_work(esw->work_queue, &host_work->work);
--
2.44.0
^ permalink raw reply related
* [PATCH net-next 3/7] net/mlx5: E-Switch, introduce generic work queue dispatch helper
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
Each E-Switch work item requires the same boilerplate: acquire the
devlink lock, check whether the work is stale, dispatch to the
appropriate handler, and release the lock. Factor this out.
Add a func callback to mlx5_host_work so the generic handler
esw_wq_handler() can dispatch to the right function without
duplicating locking logic. Introduce mlx5_esw_add_work() as the
single enqueue point: it stamps the work item with the current
generation counter and queues it onto the E-Switch work queue.
Refactor esw_vfs_changed_event_handler() to match the new contract:
it no longer receives work_gen or out as parameters. It queries
mlx5_esw_query_functions() itself and owns the kvfree() of the
result. The devlink lock is acquired and released by esw_wq_handler()
before dispatching, so the handler runs with the lock already held.
Update mlx5_esw_funcs_changed_handler() to use mlx5_esw_add_work().
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 1 +
.../mellanox/mlx5/core/eswitch_offloads.c | 77 +++++++++++--------
2 files changed, 45 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
index 0c3d2bdebf8c..e3ab8a30c174 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
@@ -336,6 +336,7 @@ struct mlx5_host_work {
struct work_struct work;
struct mlx5_eswitch *esw;
int work_gen;
+ void (*func)(struct mlx5_eswitch *esw);
};
struct mlx5_esw_functions {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index b2e7294d3a5c..23af5a12dc07 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -3655,20 +3655,15 @@ static void esw_offloads_steering_cleanup(struct mlx5_eswitch *esw)
mutex_destroy(&esw->fdb_table.offloads.vports.lock);
}
-static void
-esw_vfs_changed_event_handler(struct mlx5_eswitch *esw, int work_gen,
- const u32 *out)
+static void esw_vfs_changed_event_handler(struct mlx5_eswitch *esw)
{
- struct devlink *devlink;
bool host_pf_disabled;
u16 new_num_vfs;
+ const u32 *out;
- devlink = priv_to_devlink(esw->dev);
- devl_lock(devlink);
-
- /* Stale work from one or more mode changes ago. Bail out. */
- if (work_gen != atomic_read(&esw->generation))
- goto unlock;
+ out = mlx5_esw_query_functions(esw->dev);
+ if (IS_ERR(out))
+ return;
new_num_vfs = MLX5_GET(query_esw_functions_out, out,
host_params_context.host_num_of_vfs);
@@ -3676,7 +3671,7 @@ esw_vfs_changed_event_handler(struct mlx5_eswitch *esw, int work_gen,
host_params_context.host_pf_disabled);
if (new_num_vfs == esw->esw_funcs.num_vfs || host_pf_disabled)
- goto unlock;
+ goto free;
/* Number of VFs can only change from "0 to x" or "x to 0". */
if (esw->esw_funcs.num_vfs > 0) {
@@ -3686,54 +3681,70 @@ esw_vfs_changed_event_handler(struct mlx5_eswitch *esw, int work_gen,
err = mlx5_eswitch_load_vf_vports(esw, new_num_vfs,
MLX5_VPORT_UC_ADDR_CHANGE);
- if (err) {
- devl_unlock(devlink);
- return;
- }
+ if (err)
+ goto free;
}
esw->esw_funcs.num_vfs = new_num_vfs;
-unlock:
- devl_unlock(devlink);
+free:
+ kvfree(out);
}
-static void esw_functions_changed_event_handler(struct work_struct *work)
+static void esw_wq_handler(struct work_struct *work)
{
struct mlx5_host_work *host_work;
struct mlx5_eswitch *esw;
- const u32 *out;
+ struct devlink *devlink;
host_work = container_of(work, struct mlx5_host_work, work);
esw = host_work->esw;
+ devlink = priv_to_devlink(esw->dev);
- out = mlx5_esw_query_functions(esw->dev);
- if (IS_ERR(out))
- goto out;
+ devl_lock(devlink);
- esw_vfs_changed_event_handler(esw, host_work->work_gen, out);
- kvfree(out);
-out:
+ /* Stale work from one or more mode changes ago. Bail out. */
+ if (host_work->work_gen != atomic_read(&esw->generation))
+ goto unlock;
+
+ host_work->func(esw);
+
+unlock:
+ devl_unlock(devlink);
kfree(host_work);
}
-int mlx5_esw_funcs_changed_handler(struct notifier_block *nb, unsigned long type, void *data)
+static int mlx5_esw_add_work(struct mlx5_eswitch *esw,
+ void (*func)(struct mlx5_eswitch *esw))
{
- struct mlx5_esw_functions *esw_funcs;
struct mlx5_host_work *host_work;
- struct mlx5_eswitch *esw;
host_work = kzalloc_obj(*host_work, GFP_ATOMIC);
if (!host_work)
- return NOTIFY_DONE;
-
- esw_funcs = mlx5_nb_cof(nb, struct mlx5_esw_functions, nb);
- esw = container_of(esw_funcs, struct mlx5_eswitch, esw_funcs);
+ return -ENOMEM;
host_work->esw = esw;
host_work->work_gen = atomic_read(&esw->generation);
- INIT_WORK(&host_work->work, esw_functions_changed_event_handler);
+ host_work->func = func;
+ INIT_WORK(&host_work->work, esw_wq_handler);
queue_work(esw->work_queue, &host_work->work);
+ return 0;
+}
+
+int mlx5_esw_funcs_changed_handler(struct notifier_block *nb,
+ unsigned long type, void *data)
+{
+ struct mlx5_esw_functions *esw_funcs;
+ struct mlx5_eswitch *esw;
+ int ret;
+
+ esw_funcs = mlx5_nb_cof(nb, struct mlx5_esw_functions, nb);
+ esw = container_of(esw_funcs, struct mlx5_eswitch, esw_funcs);
+
+ ret = mlx5_esw_add_work(esw, esw_vfs_changed_event_handler);
+ if (ret)
+ return NOTIFY_DONE;
+
return NOTIFY_OK;
}
--
2.44.0
^ permalink raw reply related
* [PATCH net-next 4/7] net/mlx5: E-Switch, fix deadlock between devlink lock and esw->wq
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
mlx5_eswitch_cleanup() calls destroy_workqueue() while holding the
devlink lock (via mlx5_uninit_one()). Workers on the queue call
devl_lock() before checking whether their work is stale, which
deadlocks:
mlx5_uninit_one (holds devlink lock)
mlx5_eswitch_cleanup()
destroy_workqueue() <- waits for workers to finish
worker: devl_lock() <- blocked on
devlink lock held above
The same pattern affects mlx5_devlink_eswitch_mode_set(), which can
drain the queue while holding devlink lock.
Fix by making esw_wq_handler() check the generation counter BEFORE
acquiring the devlink lock, using devl_trylock() in a loop with
cond_resched(). If the work is stale the handler exits immediately
without ever contending for the lock.
To guarantee stale detection, increment the generation counter at
every E-Switch operation boundary:
- mlx5_eswitch_cleanup(): increment before destroy_workqueue() so
any in-flight worker sees stale and drains without blocking. Also
move mlx5_esw_qos_cleanup() to after destroy_workqueue() so it
runs only once all workers have finished.
- mlx5_devlink_eswitch_mode_set(): increment before starting the
mode change so workers from the previous mode are discarded.
- mlx5_eswitch_disable(): increment so workers queued before the
disable see stale and exit.
- mlx5_eswitch_enable() and mlx5_eswitch_disable_sriov(): increment
so in-flight work against an old VF count or mode is discarded
when these operations begin.
Remove the conditional atomic_inc() in
mlx5_eswitch_event_handler_unregister(); the mlx5_eswitch_disable()
increment now covers it unconditionally and earlier in the call chain.
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 11 +++++++----
.../mellanox/mlx5/core/eswitch_offloads.c | 18 +++++++++++++++++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 1986d4d0e886..d315484390c8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1073,10 +1073,8 @@ static void mlx5_eswitch_event_handler_register(struct mlx5_eswitch *esw)
static void mlx5_eswitch_event_handler_unregister(struct mlx5_eswitch *esw)
{
if (esw->mode == MLX5_ESWITCH_OFFLOADS &&
- mlx5_eswitch_is_funcs_handler(esw->dev)) {
+ mlx5_eswitch_is_funcs_handler(esw->dev))
mlx5_eq_notifier_unregister(esw->dev, &esw->esw_funcs.nb);
- atomic_inc(&esw->generation);
- }
}
static void mlx5_eswitch_clear_vf_vports_info(struct mlx5_eswitch *esw)
@@ -1701,6 +1699,8 @@ int mlx5_eswitch_enable(struct mlx5_eswitch *esw, int num_vfs)
if (toggle_lag)
mlx5_lag_disable_change(esw->dev);
+ atomic_inc(&esw->generation);
+
if (!mlx5_esw_is_fdb_created(esw)) {
ret = mlx5_eswitch_enable_locked(esw, num_vfs);
} else {
@@ -1745,6 +1745,7 @@ void mlx5_eswitch_disable_sriov(struct mlx5_eswitch *esw, bool clear_vf)
esw_info(esw->dev, "Unload vfs: mode(%s), nvfs(%d), necvfs(%d), active vports(%d)\n",
esw->mode == MLX5_ESWITCH_LEGACY ? "LEGACY" : "OFFLOADS",
esw->esw_funcs.num_vfs, esw->esw_funcs.num_ec_vfs, esw->enabled_vports);
+ atomic_inc(&esw->generation);
if (!mlx5_core_is_ecpf(esw->dev)) {
mlx5_eswitch_unload_vf_vports(esw, esw->esw_funcs.num_vfs);
@@ -1809,6 +1810,7 @@ void mlx5_eswitch_disable(struct mlx5_eswitch *esw)
return;
devl_assert_locked(priv_to_devlink(esw->dev));
+ atomic_inc(&esw->generation);
mlx5_lag_disable_change(esw->dev);
mlx5_eswitch_disable_locked(esw);
esw->mode = MLX5_ESWITCH_LEGACY;
@@ -2110,8 +2112,9 @@ void mlx5_eswitch_cleanup(struct mlx5_eswitch *esw)
esw_info(esw->dev, "cleanup\n");
- mlx5_esw_qos_cleanup(esw);
+ atomic_inc(&esw->generation);
destroy_workqueue(esw->work_queue);
+ mlx5_esw_qos_cleanup(esw);
WARN_ON(refcount_read(&esw->qos.refcnt));
mutex_destroy(&esw->state_lock);
WARN_ON(!xa_empty(&esw->offloads.vhca_map));
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 23af5a12dc07..988595e1b425 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -3699,7 +3699,20 @@ static void esw_wq_handler(struct work_struct *work)
esw = host_work->esw;
devlink = priv_to_devlink(esw->dev);
- devl_lock(devlink);
+ /* Check for stale work BEFORE acquiring devlink lock.
+ * mlx5_eswitch_cleanup() increments the generation counter
+ * before destroy_workqueue() while holding devlink lock,
+ * so acquiring devlink lock here would deadlock.
+ */
+ for (;;) {
+ if (host_work->work_gen != atomic_read(&esw->generation))
+ goto free;
+
+ if (devl_trylock(devlink))
+ break;
+
+ cond_resched();
+ }
/* Stale work from one or more mode changes ago. Bail out. */
if (host_work->work_gen != atomic_read(&esw->generation))
@@ -3709,6 +3722,7 @@ static void esw_wq_handler(struct work_struct *work)
unlock:
devl_unlock(devlink);
+free:
kfree(host_work);
}
@@ -4161,6 +4175,8 @@ int mlx5_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode,
goto skip;
}
+ atomic_inc(&esw->generation);
+
if (mlx5_mode == MLX5_ESWITCH_LEGACY)
esw->dev->priv.flags |= MLX5_PRIV_FLAGS_SWITCH_LEGACY;
if (mlx5_mode == MLX5_ESWITCH_OFFLOADS)
--
2.44.0
^ permalink raw reply related
* [PATCH net-next 5/7] net/mlx5: E-Switch, block representors during reconfiguration
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
Introduce a simple atomic block state via mlx5_esw_reps_block() and
mlx5_esw_reps_unblock(). Internally, mlx5_esw_mark_reps() spins a
cmpxchg between the UNBLOCKED and BLOCKED states. All E-Switch
reconfiguration paths (mode set, enable, disable, VF/SF add/del, LAG
reload) now bracket their work with this guard so representor changes
won't race with the ongoing E-Switch update, yet we remain
non-blocking and avoid new locks.
A spinlock is out because the protected work can sleep (RDMA ops,
devcom, netdev callbacks). A mutex won't work either: esw_mode_change()
has to drop the guard mid-flight so mlx5_rescan_drivers_locked() can
reload mlx5_ib, which calls back into mlx5_eswitch_register_vport_reps()
on the same thread. Beyond that, any real lock would create an ABBA
cycle: the LAG side holds the LAG lock when it calls reps_block(), and
the mlx5_ib side holds RDMA locks when it calls register_vport_reps(),
and those two subsystems talk to each other. The atomic CAS loop avoids
all of this - no lock ordering, no sleep restrictions, and the owner
can drop the guard and let a nested caller win the next transition
before reclaiming it.
With this infrastructure in place, downstream patches can safely tie
representor load/unload to the mlx5_ib module's lifecycle. Loading
mlx5_ib while the device is in switchdev mode has failed to bring up
the IB representors for years; those patches will finally fix that.
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 13 ++++
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 6 ++
.../mellanox/mlx5/core/eswitch_offloads.c | 77 +++++++++++++++++--
.../net/ethernet/mellanox/mlx5/core/lag/lag.c | 2 +
.../ethernet/mellanox/mlx5/core/sf/devlink.c | 5 ++
include/linux/mlx5/eswitch.h | 5 ++
6 files changed, 100 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index d315484390c8..a7701c9d776a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -1700,6 +1700,7 @@ int mlx5_eswitch_enable(struct mlx5_eswitch *esw, int num_vfs)
mlx5_lag_disable_change(esw->dev);
atomic_inc(&esw->generation);
+ mlx5_esw_reps_block(esw);
if (!mlx5_esw_is_fdb_created(esw)) {
ret = mlx5_eswitch_enable_locked(esw, num_vfs);
@@ -1723,6 +1724,8 @@ int mlx5_eswitch_enable(struct mlx5_eswitch *esw, int num_vfs)
}
}
+ mlx5_esw_reps_unblock(esw);
+
if (toggle_lag)
mlx5_lag_enable_change(esw->dev);
@@ -1747,6 +1750,8 @@ void mlx5_eswitch_disable_sriov(struct mlx5_eswitch *esw, bool clear_vf)
esw->esw_funcs.num_vfs, esw->esw_funcs.num_ec_vfs, esw->enabled_vports);
atomic_inc(&esw->generation);
+ mlx5_esw_reps_block(esw);
+
if (!mlx5_core_is_ecpf(esw->dev)) {
mlx5_eswitch_unload_vf_vports(esw, esw->esw_funcs.num_vfs);
if (clear_vf)
@@ -1757,6 +1762,8 @@ void mlx5_eswitch_disable_sriov(struct mlx5_eswitch *esw, bool clear_vf)
mlx5_eswitch_clear_ec_vf_vports_info(esw);
}
+ mlx5_esw_reps_unblock(esw);
+
if (esw->mode == MLX5_ESWITCH_OFFLOADS) {
struct devlink *devlink = priv_to_devlink(esw->dev);
@@ -1812,7 +1819,11 @@ void mlx5_eswitch_disable(struct mlx5_eswitch *esw)
devl_assert_locked(priv_to_devlink(esw->dev));
atomic_inc(&esw->generation);
mlx5_lag_disable_change(esw->dev);
+
+ mlx5_esw_reps_block(esw);
mlx5_eswitch_disable_locked(esw);
+ mlx5_esw_reps_unblock(esw);
+
esw->mode = MLX5_ESWITCH_LEGACY;
mlx5_lag_enable_change(esw->dev);
}
@@ -2075,6 +2086,8 @@ int mlx5_eswitch_init(struct mlx5_core_dev *dev)
init_rwsem(&esw->mode_lock);
refcount_set(&esw->qos.refcnt, 0);
atomic_set(&esw->generation, 0);
+ atomic_set(&esw->offloads.reps_conf_state,
+ MLX5_ESW_OFFLOADS_REP_TYPE_UNBLOCKED);
esw->enabled_vports = 0;
esw->offloads.inline_mode = MLX5_INLINE_MODE_NONE;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
index e3ab8a30c174..256ac3ad37bc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
@@ -315,6 +315,7 @@ struct mlx5_esw_offload {
DECLARE_HASHTABLE(termtbl_tbl, 8);
struct mutex termtbl_mutex; /* protects termtbl hash */
struct xarray vhca_map;
+ atomic_t reps_conf_state;
const struct mlx5_eswitch_rep_ops *rep_ops[NUM_REP_TYPES];
u8 inline_mode;
atomic64_t num_flows;
@@ -949,6 +950,8 @@ mlx5_esw_lag_demux_fg_create(struct mlx5_eswitch *esw,
struct mlx5_flow_handle *
mlx5_esw_lag_demux_rule_create(struct mlx5_eswitch *esw, u16 vport_num,
struct mlx5_flow_table *lag_ft);
+void mlx5_esw_reps_block(struct mlx5_eswitch *esw);
+void mlx5_esw_reps_unblock(struct mlx5_eswitch *esw);
#else /* CONFIG_MLX5_ESWITCH */
/* eswitch API stubs */
static inline int mlx5_eswitch_init(struct mlx5_core_dev *dev) { return 0; }
@@ -1026,6 +1029,9 @@ mlx5_esw_host_functions_enabled(const struct mlx5_core_dev *dev)
return true;
}
+static inline void mlx5_esw_reps_block(struct mlx5_eswitch *esw) {}
+static inline void mlx5_esw_reps_unblock(struct mlx5_eswitch *esw) {}
+
static inline bool
mlx5_esw_vport_vhca_id(struct mlx5_eswitch *esw, u16 vportn, u16 *vhca_id)
{
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 988595e1b425..4b626ffcfa8e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -2410,23 +2410,56 @@ static int esw_create_restore_table(struct mlx5_eswitch *esw)
return err;
}
+static void mlx5_esw_assert_reps_blocked(struct mlx5_eswitch *esw)
+{
+ if (atomic_read(&esw->offloads.reps_conf_state) ==
+ MLX5_ESW_OFFLOADS_REP_TYPE_BLOCKED)
+ return;
+
+ esw_warn(esw->dev, "reps state machine violated: expected BLOCKED\n");
+}
+
+static void mlx5_esw_mark_reps(struct mlx5_eswitch *esw,
+ enum mlx5_esw_offloads_rep_type_state old,
+ enum mlx5_esw_offloads_rep_type_state new)
+{
+ atomic_t *reps_conf_state = &esw->offloads.reps_conf_state;
+
+ do {
+ atomic_cond_read_relaxed(reps_conf_state, VAL == old);
+ } while (atomic_cmpxchg(reps_conf_state, old, new) != old);
+}
+
+void mlx5_esw_reps_block(struct mlx5_eswitch *esw)
+{
+ mlx5_esw_mark_reps(esw, MLX5_ESW_OFFLOADS_REP_TYPE_UNBLOCKED,
+ MLX5_ESW_OFFLOADS_REP_TYPE_BLOCKED);
+}
+
+void mlx5_esw_reps_unblock(struct mlx5_eswitch *esw)
+{
+ mlx5_esw_mark_reps(esw, MLX5_ESW_OFFLOADS_REP_TYPE_BLOCKED,
+ MLX5_ESW_OFFLOADS_REP_TYPE_UNBLOCKED);
+}
+
static void esw_mode_change(struct mlx5_eswitch *esw, u16 mode)
{
+ mlx5_esw_reps_unblock(esw);
mlx5_devcom_comp_lock(esw->dev->priv.hca_devcom_comp);
if (esw->dev->priv.flags & MLX5_PRIV_FLAGS_DISABLE_IB_ADEV ||
mlx5_core_mp_enabled(esw->dev)) {
esw->mode = mode;
- mlx5_rescan_drivers_locked(esw->dev);
- mlx5_devcom_comp_unlock(esw->dev->priv.hca_devcom_comp);
- return;
+ goto out;
}
esw->dev->priv.flags |= MLX5_PRIV_FLAGS_DISABLE_IB_ADEV;
mlx5_rescan_drivers_locked(esw->dev);
esw->mode = mode;
esw->dev->priv.flags &= ~MLX5_PRIV_FLAGS_DISABLE_IB_ADEV;
+out:
mlx5_rescan_drivers_locked(esw->dev);
mlx5_devcom_comp_unlock(esw->dev->priv.hca_devcom_comp);
+ mlx5_esw_reps_block(esw);
}
static void mlx5_esw_fdb_drop_destroy(struct mlx5_eswitch *esw)
@@ -2761,6 +2794,8 @@ void esw_offloads_cleanup(struct mlx5_eswitch *esw)
static int __esw_offloads_load_rep(struct mlx5_eswitch *esw,
struct mlx5_eswitch_rep *rep, u8 rep_type)
{
+ mlx5_esw_assert_reps_blocked(esw);
+
if (atomic_cmpxchg(&rep->rep_data[rep_type].state,
REP_REGISTERED, REP_LOADED) == REP_REGISTERED)
return esw->offloads.rep_ops[rep_type]->load(esw->dev, rep);
@@ -2771,6 +2806,8 @@ static int __esw_offloads_load_rep(struct mlx5_eswitch *esw,
static void __esw_offloads_unload_rep(struct mlx5_eswitch *esw,
struct mlx5_eswitch_rep *rep, u8 rep_type)
{
+ mlx5_esw_assert_reps_blocked(esw);
+
if (atomic_cmpxchg(&rep->rep_data[rep_type].state,
REP_LOADED, REP_REGISTERED) == REP_LOADED) {
if (rep_type == REP_ETH)
@@ -3673,6 +3710,7 @@ static void esw_vfs_changed_event_handler(struct mlx5_eswitch *esw)
if (new_num_vfs == esw->esw_funcs.num_vfs || host_pf_disabled)
goto free;
+ mlx5_esw_reps_block(esw);
/* Number of VFs can only change from "0 to x" or "x to 0". */
if (esw->esw_funcs.num_vfs > 0) {
mlx5_eswitch_unload_vf_vports(esw, esw->esw_funcs.num_vfs);
@@ -3682,9 +3720,11 @@ static void esw_vfs_changed_event_handler(struct mlx5_eswitch *esw)
err = mlx5_eswitch_load_vf_vports(esw, new_num_vfs,
MLX5_VPORT_UC_ADDR_CHANGE);
if (err)
- goto free;
+ goto unblock;
}
esw->esw_funcs.num_vfs = new_num_vfs;
+unblock:
+ mlx5_esw_reps_unblock(esw);
free:
kvfree(out);
}
@@ -4164,6 +4204,7 @@ int mlx5_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode,
goto unlock;
}
+ mlx5_esw_reps_block(esw);
esw->eswitch_operation_in_progress = true;
up_write(&esw->mode_lock);
@@ -4203,6 +4244,7 @@ int mlx5_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode,
mlx5_devlink_netdev_netns_immutable_set(devlink, false);
down_write(&esw->mode_lock);
esw->eswitch_operation_in_progress = false;
+ mlx5_esw_reps_unblock(esw);
unlock:
mlx5_esw_unlock(esw);
enable_lag:
@@ -4474,9 +4516,10 @@ mlx5_eswitch_vport_has_rep(const struct mlx5_eswitch *esw, u16 vport_num)
return true;
}
-void mlx5_eswitch_register_vport_reps(struct mlx5_eswitch *esw,
- const struct mlx5_eswitch_rep_ops *ops,
- u8 rep_type)
+static void
+mlx5_eswitch_register_vport_reps_blocked(struct mlx5_eswitch *esw,
+ const struct mlx5_eswitch_rep_ops *ops,
+ u8 rep_type)
{
struct mlx5_eswitch_rep_data *rep_data;
struct mlx5_eswitch_rep *rep;
@@ -4491,9 +4534,20 @@ void mlx5_eswitch_register_vport_reps(struct mlx5_eswitch *esw,
}
}
}
+
+void mlx5_eswitch_register_vport_reps(struct mlx5_eswitch *esw,
+ const struct mlx5_eswitch_rep_ops *ops,
+ u8 rep_type)
+{
+ mlx5_esw_reps_block(esw);
+ mlx5_eswitch_register_vport_reps_blocked(esw, ops, rep_type);
+ mlx5_esw_reps_unblock(esw);
+}
EXPORT_SYMBOL(mlx5_eswitch_register_vport_reps);
-void mlx5_eswitch_unregister_vport_reps(struct mlx5_eswitch *esw, u8 rep_type)
+static void
+mlx5_eswitch_unregister_vport_reps_blocked(struct mlx5_eswitch *esw,
+ u8 rep_type)
{
struct mlx5_eswitch_rep *rep;
unsigned long i;
@@ -4504,6 +4558,13 @@ void mlx5_eswitch_unregister_vport_reps(struct mlx5_eswitch *esw, u8 rep_type)
mlx5_esw_for_each_rep(esw, i, rep)
atomic_set(&rep->rep_data[rep_type].state, REP_UNREGISTERED);
}
+
+void mlx5_eswitch_unregister_vport_reps(struct mlx5_eswitch *esw, u8 rep_type)
+{
+ mlx5_esw_reps_block(esw);
+ mlx5_eswitch_unregister_vport_reps_blocked(esw, rep_type);
+ mlx5_esw_reps_unblock(esw);
+}
EXPORT_SYMBOL(mlx5_eswitch_unregister_vport_reps);
void *mlx5_eswitch_get_uplink_priv(struct mlx5_eswitch *esw, u8 rep_type)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
index c402a8463081..ff2e6f6caa0c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lag/lag.c
@@ -1105,7 +1105,9 @@ int mlx5_lag_reload_ib_reps(struct mlx5_lag *ldev, u32 flags)
struct mlx5_eswitch *esw;
esw = pf->dev->priv.eswitch;
+ mlx5_esw_reps_block(esw);
ret = mlx5_eswitch_reload_ib_reps(esw);
+ mlx5_esw_reps_unblock(esw);
if (ret)
return ret;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c b/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c
index 8503e532f423..2fc69897e35b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/sf/devlink.c
@@ -245,8 +245,10 @@ static int mlx5_sf_add(struct mlx5_core_dev *dev, struct mlx5_sf_table *table,
if (IS_ERR(sf))
return PTR_ERR(sf);
+ mlx5_esw_reps_block(esw);
err = mlx5_eswitch_load_sf_vport(esw, sf->hw_fn_id, MLX5_VPORT_UC_ADDR_CHANGE,
&sf->dl_port, new_attr->controller, new_attr->sfnum);
+ mlx5_esw_reps_unblock(esw);
if (err)
goto esw_err;
*dl_port = &sf->dl_port.dl_port;
@@ -367,7 +369,10 @@ int mlx5_devlink_sf_port_del(struct devlink *devlink,
struct mlx5_sf_table *table = dev->priv.sf_table;
struct mlx5_sf *sf = mlx5_sf_by_dl_port(dl_port);
+ mlx5_esw_reps_block(dev->priv.eswitch);
mlx5_sf_del(table, sf);
+ mlx5_esw_reps_unblock(dev->priv.eswitch);
+
return 0;
}
diff --git a/include/linux/mlx5/eswitch.h b/include/linux/mlx5/eswitch.h
index 67256e776566..786b1ea83843 100644
--- a/include/linux/mlx5/eswitch.h
+++ b/include/linux/mlx5/eswitch.h
@@ -29,6 +29,11 @@ enum {
REP_LOADED,
};
+enum mlx5_esw_offloads_rep_type_state {
+ MLX5_ESW_OFFLOADS_REP_TYPE_UNBLOCKED,
+ MLX5_ESW_OFFLOADS_REP_TYPE_BLOCKED,
+};
+
enum mlx5_switchdev_event {
MLX5_SWITCHDEV_EVENT_PAIR,
MLX5_SWITCHDEV_EVENT_UNPAIR,
--
2.44.0
^ permalink raw reply related
* [PATCH net-next 6/7] net/mlx5: E-switch, load reps via work queue after registration
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
mlx5_eswitch_register_vport_reps() merely sets the callbacks. The actual
representor load/unload requires devlink locking and shouldn’t run from
the registration context. Queue a work that acquires the devlink lock,
loads all relevant reps. This lets load happen where the needed locks
can be taken.
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
.../mellanox/mlx5/core/eswitch_offloads.c | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 4b626ffcfa8e..279490c0074c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -4535,6 +4535,38 @@ mlx5_eswitch_register_vport_reps_blocked(struct mlx5_eswitch *esw,
}
}
+static void mlx5_eswitch_reload_reps_blocked(struct mlx5_eswitch *esw)
+{
+ struct mlx5_vport *vport;
+ unsigned long i;
+
+ if (esw->mode != MLX5_ESWITCH_OFFLOADS)
+ return;
+
+ if (mlx5_esw_offloads_rep_load(esw, MLX5_VPORT_UPLINK))
+ return;
+
+ mlx5_esw_for_each_vport(esw, i, vport) {
+ if (!vport)
+ continue;
+ if (!vport->enabled)
+ continue;
+ if (vport->vport == MLX5_VPORT_UPLINK)
+ continue;
+ if (!mlx5_eswitch_vport_has_rep(esw, vport->vport))
+ continue;
+
+ mlx5_esw_offloads_rep_load(esw, vport->vport);
+ }
+}
+
+static void mlx5_eswitch_reload_reps(struct mlx5_eswitch *esw)
+{
+ mlx5_esw_reps_block(esw);
+ mlx5_eswitch_reload_reps_blocked(esw);
+ mlx5_esw_reps_unblock(esw);
+}
+
void mlx5_eswitch_register_vport_reps(struct mlx5_eswitch *esw,
const struct mlx5_eswitch_rep_ops *ops,
u8 rep_type)
@@ -4542,6 +4574,8 @@ void mlx5_eswitch_register_vport_reps(struct mlx5_eswitch *esw,
mlx5_esw_reps_block(esw);
mlx5_eswitch_register_vport_reps_blocked(esw, ops, rep_type);
mlx5_esw_reps_unblock(esw);
+
+ mlx5_esw_add_work(esw, mlx5_eswitch_reload_reps);
}
EXPORT_SYMBOL(mlx5_eswitch_register_vport_reps);
--
2.44.0
^ permalink raw reply related
* [PATCH net-next 7/7] net/mlx5: Add profile to auto-enable switchdev mode at device init
From: Tariq Toukan @ 2026-04-09 11:55 UTC (permalink / raw)
To: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Moshe Shemesh, Kees Cook, Patrisious Haddad,
Gerd Bayer, Parav Pandit, Cosmin Ratiu, Carolina Jubran, netdev,
linux-rdma, linux-kernel, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260409115550.156419-1-tariqt@nvidia.com>
From: Mark Bloch <mbloch@nvidia.com>
Deployments that always operate in switchdev mode currently require
manual devlink configuration after driver probe, which complicates
automated provisioning.
Introduce MLX5_PROF_MASK_DEF_SWITCHDEV, a new profile mask bit, and
profile index 4. When a device is initialized or reloaded with this
profile, the driver automatically switches the e-switch to switchdev
mode by calling mlx5_devlink_eswitch_mode_set() immediately after
bringing the device online.
A no-op stub of mlx5_devlink_eswitch_mode_set() is added for builds
without CONFIG_MLX5_ESWITCH.
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 6 +++++
.../net/ethernet/mellanox/mlx5/core/main.c | 26 ++++++++++++++++++-
include/linux/mlx5/driver.h | 1 +
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
index 256ac3ad37bc..5dcca59c3125 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
@@ -1047,6 +1047,12 @@ mlx5_esw_lag_demux_rule_create(struct mlx5_eswitch *esw, u16 vport_num,
return ERR_PTR(-EOPNOTSUPP);
}
+static inline int
+mlx5_devlink_eswitch_mode_set(struct devlink *devlink, u16 mode,
+ struct netlink_ext_ack *extack)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_MLX5_ESWITCH */
#endif /* __MLX5_ESWITCH_H__ */
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index dc7f20a357d9..12f39b4b6c2a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -86,7 +86,7 @@ MODULE_PARM_DESC(debug_mask, "debug mask: 1 = dump cmd data, 2 = dump cmd exec t
static unsigned int prof_sel = MLX5_DEFAULT_PROF;
module_param_named(prof_sel, prof_sel, uint, 0444);
-MODULE_PARM_DESC(prof_sel, "profile selector. Valid range 0 - 2");
+MODULE_PARM_DESC(prof_sel, "profile selector. Valid range 0 - 4");
static u32 sw_owner_id[4];
#define MAX_SW_VHCA_ID (BIT(__mlx5_bit_sz(cmd_hca_cap_2, sw_vhca_id)) - 1)
@@ -185,6 +185,11 @@ static struct mlx5_profile profile[] = {
.log_max_qp = LOG_MAX_SUPPORTED_QPS,
.num_cmd_caches = 0,
},
+ [4] = {
+ .mask = MLX5_PROF_MASK_DEF_SWITCHDEV | MLX5_PROF_MASK_QP_SIZE,
+ .log_max_qp = LOG_MAX_SUPPORTED_QPS,
+ .num_cmd_caches = MLX5_NUM_COMMAND_CACHES,
+ },
};
static int wait_fw_init(struct mlx5_core_dev *dev, u32 max_wait_mili,
@@ -1451,6 +1456,17 @@ static void mlx5_unload(struct mlx5_core_dev *dev)
mlx5_free_bfreg(dev, &dev->priv.bfreg);
}
+static void mlx5_set_default_switchdev(struct mlx5_core_dev *dev)
+{
+ int err;
+
+ err = mlx5_devlink_eswitch_mode_set(priv_to_devlink(dev),
+ DEVLINK_ESWITCH_MODE_SWITCHDEV,
+ NULL);
+ if (err && err != -EOPNOTSUPP)
+ mlx5_core_warn(dev, "failed setting switchdev as default\n");
+}
+
int mlx5_init_one_devl_locked(struct mlx5_core_dev *dev)
{
bool light_probe = mlx5_dev_is_lightweight(dev);
@@ -1497,6 +1513,10 @@ int mlx5_init_one_devl_locked(struct mlx5_core_dev *dev)
mlx5_core_err(dev, "mlx5_hwmon_dev_register failed with error code %d\n", err);
mutex_unlock(&dev->intf_state_mutex);
+
+ if (dev->profile.mask & MLX5_PROF_MASK_DEF_SWITCHDEV)
+ mlx5_set_default_switchdev(dev);
+
return 0;
err_register:
@@ -1598,6 +1618,10 @@ int mlx5_load_one_devl_locked(struct mlx5_core_dev *dev, bool recovery)
goto err_attach;
mutex_unlock(&dev->intf_state_mutex);
+
+ if (dev->profile.mask & MLX5_PROF_MASK_DEF_SWITCHDEV)
+ mlx5_set_default_switchdev(dev);
+
return 0;
err_attach:
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 1268fcf35ec7..cfbc0ff6292a 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -706,6 +706,7 @@ struct mlx5_st;
enum {
MLX5_PROF_MASK_QP_SIZE = (u64)1 << 0,
MLX5_PROF_MASK_MR_CACHE = (u64)1 << 1,
+ MLX5_PROF_MASK_DEF_SWITCHDEV = (u64)1 << 2,
};
enum {
--
2.44.0
^ permalink raw reply related
* RE: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
From: Biju Das @ 2026-04-09 11:58 UTC (permalink / raw)
To: Russell King
Cc: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <adeNzh3eu9PSdEas@shell.armlinux.org.uk>
Hi Russell King,
> -----Original Message-----
> From: Russell King <linux@armlinux.org.uk>
> Sent: 09 April 2026 12:30
> Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove ksz9131_resume()
>
> On Thu, Apr 09, 2026 at 11:19:43AM +0000, Biju Das wrote:
> > Hi Russell King,
> >
> > > -----Original Message-----
> > > From: Russell King <linux@armlinux.org.uk>
> > > Sent: 09 April 2026 12:05
> > > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove
> > > ksz9131_resume()
> > >
> > > On Thu, Apr 09, 2026 at 10:52:35AM +0000, Biju Das wrote:
> > > > Hi Russell King,
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > > -----Original Message-----
> > > > > From: Russell King <linux@armlinux.org.uk>
> > > > > Sent: 09 April 2026 11:30
> > > > > Subject: Re: [PATCH net v2 2/2] net: phy: micrel: remove
> > > > > ksz9131_resume()
> > > > >
> > > > > phy_init_hw() will also call drv->config_intr(), so that doesn't need to be done either.
> > > > >
> > > > > It will also call drv->config_init(), which will call kszphy_config_reset().
> > > > >
> > > > > So most of kszphy_resume() becomes unnecessary. I think the only
> > > > > thing that remains would be the call to kszphy_enable_clk() -
> > > > > and is it fine to call that after
> > > phy_init_hw() ?
> > > >
> > > > It just needs kszphy_enable_clk() and phydev->drv->config_intr()
> > > > to enable PHY interrupts for suspend-to-RAM to work on RZ/G3E SMARC EVK.
> > >
> > > I think you mean WoL rather than suspend-to-RAM, although I don't
> > > see anything in micrel.c that hints that WoL is supported, so please explain why and how the PHY
> interrupt impacts suspend-to-RAM.
> >
> > This is not WoL. During Suspend-to-RAM, the DDR goes into retention
> > mode while the CPU, SoC, and PHY power is cut off.
> >
> > During resume, TF-A detects WARM_RESET, brings DDR out of retention,
> > and jumps to the PSCI resume path.
> >
> > >
> > > Note that a particular interrupt should not wake the system unless
> > > enable_irq_wake() has been called for that specific interrupt.
> >
> > If PHY interrupts are not configured during resume, no link interrupt is received and the message:
> > "renesas-gbeth 11c30000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx"
> > is not seen, as shown in [1].
>
> ... and why does that happen? Is it because the PHY has lost its interrupt configuration and that needs
> to be reprogrammed?
Yes, but phy_init_hw() reconfigures the PHY interrupt during resume.
This is due to phydev->interrupts = PHY_INTERRUPT_DISABLED; in the suspend path, as you mentioned below.
>
> If you don't disable the PHY interrupt in the suspend path, then will the call to drv->config_intr()
> via phy_init_hw() before
> phy_resume() be sufficient?
Yes, I confirm that if the PHY interrupt is not disabled in the suspend path, the call to
drv->config_intr() via phy_init_hw() before phy_resume() would be sufficient.
Cheers,
Biju
^ 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