* Re: [RFC PATCH net-next 1/2] net: napi: Fix interrupts permanently disabled during busy poll
From: Jakub Kicinski @ 2026-04-29 22:52 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Martin Karsten, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Daniel Borkmann, Björn Töpel,
Gal Pressman, Tariq Toukan, Joe Damato, Frederik Deweerdt, netdev,
linux-kernel
In-Reply-To: <plfaoeyx3xfujleux6gmmlku3ancnp73g4aca7ep53zijbhjka@3ylcijhron2m>
On Wed, 29 Apr 2026 08:13:55 +0000 Dragos Tatulea wrote:
> On Tue, Apr 28, 2026 at 05:31:54PM -0700, Jakub Kicinski wrote:
> > On Tue, 28 Apr 2026 20:04:13 -0400 Martin Karsten wrote:
> > > Labelling this with number 4. might be misleading, sorry! The concern is
> > > that a short enough timer (compared to the duration of the driver poll)
> > > can be triggered before the NAPI_STATE_SCHED bit is cleared at the end
> > > of Step 3.3.
> >
> > Ah. Just say that :D Two pages of buggy text, y'all would have been
> > better off using this one paragraph as the commit message.
> > Please don't use AI for generating commit messages if that's the cause.
> > It really is spectacularly shit at it.
> I take the blame for this. Funnily enough, the text was written mostly
> without AI... Just wanted to present the interactions in a more explanatory
> way.
Heh, I guess I blame everything on AI these days :)
> Do you prefer the short version from Martin or an improved version of
> the long explanation?
That's what I'd do. The explanation should focus on the fact that the
current code arms the timer before it releases the ownership (clearing
STATE_SCHED). The intention of the __busy_poll_stop() outro is to either
schedule NAPI, arm the IRQ or the timer.
^ permalink raw reply
* Re: [PATCH net-next v9 0/5] TLS read_sock performance scalability
From: Jakub Kicinski @ 2026-04-29 23:13 UTC (permalink / raw)
To: Chuck Lever
Cc: John Fastabend, Sabrina Dubroca, Eric Dumazet, Simon Horman,
Paolo Abeni, netdev, kernel-tls-handshake, Chuck Lever,
Hannes Reinecke, Alistair Francis
In-Reply-To: <20260429-tls-read-sock-v9-0-39e71aa7810f@oracle.com>
On Wed, 29 Apr 2026 17:48:07 -0400 Chuck Lever wrote:
> Changes since v8:
> - Address review comments from sashiko
> - Patch 2: Requeue partially consumed skb to prevent leak
> - Patch 5: Re-check sk_err so RST during flush surfaces as
> -ECONNRESET instead of EOF
> - Address review comments from gpt-5.5
Is someone running gpt-5.5 on the public submissions?
> - Patch 4: Restore msg_ready early-return in tls_strp_check_rcv()
> so the queued strp_work doesn't double-wake the consumer
> - Patch 4: Add tls_strparser msg_announced bit so the recvmsg
> exit-point handoff doesn't re-fire saved_data_ready() for a
> record BH or the worker already announced (rx_list-only drain
> path)
^ permalink raw reply
* Re: [PATCH net-next v9 0/5] TLS read_sock performance scalability
From: Chuck Lever @ 2026-04-29 23:15 UTC (permalink / raw)
To: Jakub Kicinski
Cc: John Fastabend, Sabrina Dubroca, Eric Dumazet, Simon Horman,
Paolo Abeni, netdev, kernel-tls-handshake, Chuck Lever,
Hannes Reinecke, Alistair Francis
In-Reply-To: <20260429161338.6da2b22d@kernel.org>
On Wed, Apr 29, 2026, at 7:13 PM, Jakub Kicinski wrote:
> On Wed, 29 Apr 2026 17:48:07 -0400 Chuck Lever wrote:
>> Changes since v8:
>> - Address review comments from sashiko
>> - Patch 2: Requeue partially consumed skb to prevent leak
>> - Patch 5: Re-check sk_err so RST during flush surfaces as
>> -ECONNRESET instead of EOF
>> - Address review comments from gpt-5.5
>
> Is someone running gpt-5.5 on the public submissions?
>
>> - Patch 4: Restore msg_ready early-return in tls_strp_check_rcv()
>> so the queued strp_work doesn't double-wake the consumer
>> - Patch 4: Add tls_strparser msg_announced bit so the recvmsg
>> exit-point handoff doesn't re-fire saved_data_ready() for a
>> record BH or the worker already announced (rx_list-only drain
>> path)
I'm using codex to review the patches.
--
Chuck Lever
^ permalink raw reply
* Re: [syzbot] [net?] WARNING: ODEBUG bug in lane_ioctl (3)
From: Jakub Kicinski @ 2026-04-29 23:17 UTC (permalink / raw)
To: Arjan van de Ven
Cc: netdev, syzbot+ca9d5686d06994c6547c, davem, edumazet, horms,
linux-kernel, pabeni, syzkaller-bugs
In-Reply-To: <20260429151741.660828-1-arjan@linux.intel.com>
On Wed, 29 Apr 2026 08:17:41 -0700 Arjan van de Ven wrote:
> This email is created by automation to help kernel developers deal with
> a large volume of bug reports by decoding oopses into more actionable
> information.
Just one opinion but I don't think it is helping me.
I'd assume at this point that maintainers can run the syzbot reports
thru their own slop generators if they want to?
And hopefully those local slop generators would notice obvious facts
like that this is a report for code which no longer exists upstream :\
^ permalink raw reply
* [PATCH v2 0/2] netfilter: fix NULL ops dereference in iptable lazy init
From: Tristan Madani @ 2026-04-29 23:18 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Phil Sutter, Florian Westphal, netfilter-devel, netdev, stable,
linux-kernel
In-Reply-To: <20260429175613.1459342-1-tristmd@gmail.com>
v1 moved the ops allocation before xt_register_table(), but as Phil
Sutter pointed out, new_table->ops is still assigned after the table
becomes visible via list_add() inside xt_register_table(). The race
window was reduced but not eliminated.
v2 takes a different approach: guard the pre_exit path against a NULL
ops pointer. If cleanup_net races against lazy table init and finds the
table before ops has been assigned, it simply skips the
nf_unregister_net_hooks() call. The register path will either complete
normally or fail and clean up via __ipt_unregister_table().
v1: https://lore.kernel.org/netdev/20260429175613.1459342-1-tristmd@gmail.com/
Tristan Madani (2):
netfilter: ip_tables: guard ipt_unregister_table_pre_exit against NULL ops
netfilter: ip6_tables: guard ip6t_unregister_table_pre_exit against NULL ops
net/ipv4/netfilter/ip_tables.c | 2 +-
net/ipv6/netfilter/ip6_tables.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v2 1/2] netfilter: ip_tables: guard ipt_unregister_table_pre_exit against NULL ops
From: Tristan Madani @ 2026-04-29 23:19 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Phil Sutter, Florian Westphal, netfilter-devel, netdev, stable,
linux-kernel
In-Reply-To: <177750472539.3004201.15967003942391945312@talencesecurity.com>
ipt_register_table() adds the table to the per-netns list via
xt_register_table() before assigning the per-net ops copy to
new_table->ops. If cleanup_net runs during this window,
ipt_unregister_table_pre_exit() finds the table via xt_find_table()
and passes the NULL ops pointer to nf_unregister_net_hooks(), causing
a general protection fault.
Guard against this by checking table->ops before calling
nf_unregister_net_hooks(). If ops is NULL the table is still being
set up; the register path will either complete and register the hooks
normally, or fail and clean up via __ipt_unregister_table().
Fixes: ae689334225f ("netfilter: xtables: Bring back xt_register_table()")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
net/ipv4/netfilter/ip_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index XXXXXXX..XXXXXXX 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1795,7 +1795,7 @@ void ipt_unregister_table_pre_exit(struct net *net, const char *name)
{
struct xt_table *table = xt_find_table(net, NFPROTO_IPV4, name);
- if (table)
+ if (table && table->ops)
nf_unregister_net_hooks(net, table->ops, hweight32(table->valid_hooks));
}
^ permalink raw reply
* [PATCH v2 2/2] netfilter: ip6_tables: guard ip6t_unregister_table_pre_exit against NULL ops
From: Tristan Madani @ 2026-04-29 23:19 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Phil Sutter, Florian Westphal, netfilter-devel, netdev, stable,
linux-kernel
In-Reply-To: <177750472539.3004201.15967003942391945312@talencesecurity.com>
Same race as the ipv4 counterpart: ip6t_register_table() adds the
table to the per-netns list before assigning new_table->ops.
cleanup_net can find the table with a NULL ops pointer and crash in
nf_unregister_net_hooks().
Guard against this by checking table->ops before the call.
Fixes: ee177a54413a ("netfilter: ip6_tables: Use xt_register_table()")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
net/ipv6/netfilter/ip6_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index XXXXXXX..XXXXXXX 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -1804,7 +1804,7 @@ void ip6t_unregister_table_pre_exit(struct net *net, const char *name)
{
struct xt_table *table = xt_find_table(net, NFPROTO_IPV6, name);
- if (table)
+ if (table && table->ops)
nf_unregister_net_hooks(net, table->ops, hweight32(table->valid_hooks));
}
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: bcmasp: Divide init to allow partial bring up
From: Jakub Kicinski @ 2026-04-29 23:20 UTC (permalink / raw)
To: justin.chen
Cc: Jakub Kicinski, netdev, bcm-kernel-feedback-list, pabeni,
edumazet, davem, andrew+netdev, florian.fainelli
In-Reply-To: <20260428220858.2076469-2-justin.chen@broadcom.com>
This is an AI-generated review of your patch. The human sending this
email says "Blindly sending out since there will be a repost,
anyway."
---
net: bcmasp: Divide init to allow partial bring up
To prepare for a partial bring up of the interface during resume,
we break apart the bcmasp_netif_init() function into smaller chunks
that can be called as necessary.
> diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> index ec63f50a849e..aff0a6d84126 100644
> --- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> +++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
[ ... ]
> -static void umac_reset(struct bcmasp_intf *intf)
> +static void umac_reset_and_init(struct bcmasp_intf *intf,
> + const unsigned char *addr)
> {
> + struct phy_device *phydev = intf->ndev->phydev;
> + u32 mac0, mac1;
>
> umac_wl(intf, 0x0, UMC_CMD);
> umac_wl(intf, UMC_CMD_SW_RESET, UMC_CMD);
> usleep_range(10, 100);
> /* We hold the umac in reset and bring it out of
> * reset when phy link is up.
> */
> -}
>
> -static void umac_set_hw_addr(struct bcmasp_intf *intf,
> - const unsigned char *addr)
> -{
> - u32 mac0 = (addr[0] << 24) | (addr[1] << 16) | (addr[2] << 8) |
> - addr[3];
> - u32 mac1 = (addr[4] << 8) | addr[5];
> + umac_wl(intf, 0x800, UMC_FRM_LEN);
> + umac_wl(intf, 0xffff, UMC_PAUSE_CNTRL);
> + umac_wl(intf, 0x800, UMC_RX_MAX_PKT_SZ);
> +
> + mac0 = (addr[0] << 24) | (addr[1] << 16) | (addr[2] << 8) |
> + addr[3];
> + mac1 = (addr[4] << 8) | addr[5];
>
> umac_wl(intf, mac0, UMC_MAC0);
> umac_wl(intf, mac1, UMC_MAC1);
> +
> + /* Reset shadow values since we reset the umac */
> + intf->old_duplex = -1;
> + intf->old_link = -1;
> + intf->old_pause = -1;
> + phydev->eee_cfg.tx_lpi_timer = umac_rl(intf, UMC_EEE_LPI_TIMER);
> }
Since UMC_CMD_SW_RESET was just asserted above, won't reading
UMC_EEE_LPI_TIMER here return 0 or a hardware default value, effectively
overwriting the bootloader-configured EEE TX LPI timer?
Also, since umac_reset_and_init() is now called unconditionally during
bcmasp_interface_resume(), does this dangerously overwrite
phydev->eee_cfg.tx_lpi_timer without holding mutex_lock(&phydev->lock)?
This seems like it could create a data race with concurrent accesses, for
example from ethtool.
[ ... ]
> +static void bcmasp_netif_init(struct net_device *dev)
> +{
> + struct bcmasp_intf *intf = netdev_priv(dev);
>
> bcmasp_init_tx(intf);
> netif_napi_add_tx(intf->ndev, &intf->tx_napi, bcmasp_tx_poll);
This existed prior to this patch, but since bcmasp_netif_init() and
bcmasp_netif_deinit() are called directly from bcmasp_interface_resume()
and bcmasp_interface_suspend() (which execute asynchronously without
rtnl_lock), can modifying the global dev->napi_list via netif_napi_add_tx()
and netif_napi_del() cause a race condition with concurrent list readers?
Suspend and resume paths typically rely on napi_enable() and napi_disable()
rather than adding and deleting the NAPI structures entirely.
[ ... ]
> @@ -1454,17 +1436,19 @@ int bcmasp_interface_resume(struct bcmasp_intf *intf)
> if (ret)
> return ret;
>
> - ret = bcmasp_netif_init(dev, false);
> - if (ret)
> - goto out;
> + bcmasp_core_clock_set_intf(intf, true);
>
> bcmasp_resume_from_wol(intf);
>
> + bcmasp_phy_hw_prepare(intf);
> +
> + umac_reset_and_init(intf, dev->dev_addr);
> +
If Wake-on-LAN is disabled, bcmasp_interface_suspend() un-prepares the PHY
by asserting reset and disabling clocks. By calling bcmasp_resume_from_wol()
before bcmasp_phy_hw_prepare(), if EEE is enabled and invokes eee_fixup(),
won't the MDIO access timeout or cause a bus error because the PHY hardware
isn't prepared yet?
Additionally, won't any WOL state changes (like clearing
UMC_MPD_CTRL_MPD_EN) be immediately wiped out by the MAC software reset
inside the subsequent umac_reset_and_init() call?
I noticed this is fixed later in the series by commit 6994d859a69dd
(net: bcmasp: Keep PHY link during WoL sleep cycle), but does leaving it
like this here break bisection?
> + bcmasp_netif_init(dev);
> +
> + phy_start(dev->phydev);
> +
> netif_device_attach(dev);
>
> return 0;
> -
> -out:
> - clk_disable_unprepare(intf->parent->clk);
> - return ret;
> }
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: bcmasp: Keep PHY link during WoL sleep cycle
From: Jakub Kicinski @ 2026-04-29 23:20 UTC (permalink / raw)
To: justin.chen
Cc: Jakub Kicinski, netdev, bcm-kernel-feedback-list, pabeni,
edumazet, davem, andrew+netdev, florian.fainelli
In-Reply-To: <20260428220858.2076469-3-justin.chen@broadcom.com>
This is an AI-generated review of your patch. The human sending this
email says "Blindly sending out since there will be a repost,
anyway."
---
net: bcmasp: Keep PHY link during WoL sleep cycle
We currently more or less restart all the HW on resume. Since we also
stop the PHY, it takes a while for the PHY link to be re-negotiated on
resume. Instead of doing a full restart, we keep the HW state and the
PHY link, that way we can resume network traffic with a much smaller
delay.
> diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> index aff0a6d84126..bab2a4f82e4e 100644
> --- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> +++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
[ ... ]
> @@ -1383,15 +1384,20 @@ int bcmasp_interface_suspend(struct bcmasp_intf *intf)
> {
> struct device *kdev = &intf->parent->pdev->dev;
> struct net_device *dev = intf->ndev;
> + bool wake;
>
> if (!netif_running(dev))
> return 0;
>
> netif_device_detach(dev);
>
> - bcmasp_netif_deinit(dev);
> + wake = device_may_wakeup(kdev) && intf->wolopts;
>
> - if (!intf->wolopts) {
> + bcmasp_netif_deinit(dev, !wake);
> +
> + if (wake) {
> + bcmasp_suspend_to_wol(intf);
> + } else {
> bcmasp_phy_hw_unprepare(intf);
>
> /* If Wake-on-LAN is disabled, we can safely
> @@ -1400,9 +1406,6 @@ int bcmasp_interface_suspend(struct bcmasp_intf *intf)
> bcmasp_core_clock_set_intf(intf, false);
> }
>
> - if (device_may_wakeup(kdev) && intf->wolopts)
> - bcmasp_suspend_to_wol(intf);
> -
> clk_disable_unprepare(intf->parent->clk);
If wake is true, phy_stop() is skipped during bcmasp_netif_deinit().
This leaves the phylib state machine active and polling on its delayed
workqueue.
At the end of bcmasp_interface_suspend(), the main MAC clock is
unconditionally disabled via clk_disable_unprepare(intf->parent->clk).
If the PHY state machine executes while this clock is disabled, will it
attempt to access PHY registers over the MDIO bus, resulting in a
synchronous external abort (bus fault) or kernel panic?
Could the active state machine also concurrently invoke the MAC's
adjust_link callback while bcmasp_interface_resume() is executing,
causing a data race on MAC registers?
> return 0;
> }
> @@ -1426,8 +1429,11 @@ static void bcmasp_resume_from_wol(struct bcmasp_intf *intf)
>
> int bcmasp_interface_resume(struct bcmasp_intf *intf)
> {
[ ... ]
> + /* The interface might be HW reset in some suspend modes, so we may
> + * need to restore the UNIMAC/PHY if that is the case.
> + */
> + reg = umac_rl(intf, UMC_CMD);
> + if (wake && (reg & UMC_CMD_RX_EN)) {
> + umac_enable_set(intf, UMC_CMD_TX_EN, 1);
> + bcmasp_resume_from_wol(intf);
> + } else {
> + bcmasp_phy_hw_prepare(intf);
> + umac_reset_and_init(intf, dev->dev_addr);
> + }
If wake is true but the MAC hardware was reset (reg & UMC_CMD_RX_EN
is false), the code branches to the else block and skips calling
bcmasp_resume_from_wol().
Since bcmasp_resume_from_wol() is responsible for reversing the WoL
configuration applied during suspend (like restoring the EEE fixup state
and masking the wakeup interrupt), does skipping this teardown leave the
wakeup interrupt unmasked during normal operation and risk an interrupt
storm?
> bcmasp_netif_init(dev);
>
> - phy_start(dev->phydev);
> + /* If HW was reset, we need to force a link re-negotiation */
> + if (wake && !(reg & UMC_CMD_RX_EN)) {
> + phy_restart_aneg(dev->phydev);
If the user has explicitly configured forced speed and duplex with
autonegotiation disabled, will this unconditional call to
phy_restart_aneg() override the user's configuration? It appears to
enable autonegotiation without checking if phydev->autoneg ==
AUTONEG_ENABLE.
Also, because phy_stop() was skipped during suspend, the PHY state
machine is still actively running in the background. Does calling
phy_restart_aneg() without holding phydev->lock create a data race
with the concurrent PHY state machine?
> + phy_trigger_machine(dev->phydev);
> + } else if (!wake) {
> + phy_start(dev->phydev);
> + }
>
> netif_device_attach(dev);
^ permalink raw reply
* Re: [PATCH net-next] net: phy: broadcom: Save PHY counters during suspend
From: Jakub Kicinski @ 2026-04-29 23:22 UTC (permalink / raw)
To: justin.chen
Cc: Jakub Kicinski, netdev, pabeni, edumazet, davem, linux,
hkallweit1, andrew, bcm-kernel-feedback-list
In-Reply-To: <20260428212424.1828999-1-justin.chen@broadcom.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: phy: broadcom: Save PHY counters during suspend
The PHY counters can be lost if the PHY is reset during suspend. We
need to save the values into the shadow counters or the accounting
will be incorrect over multiple suspend and resume cycles.
> diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
> --- a/drivers/net/phy/bcm7xxx.c
> +++ b/drivers/net/phy/bcm7xxx.c
> @@ -733,6 +733,7 @@ static int bcm7xxx_config_init(struct phy_device *phydev)
> */
> static int bcm7xxx_suspend(struct phy_device *phydev)
> {
> + struct bcm7xxx_phy_priv *priv = phydev->priv;
> int ret;
[ ... ]
> unsigned int i;
>
> + mutex_lock(&phydev->lock);
> + bcm_phy_update_stats_shadow(phydev, priv->stats);
Does this cause a NULL pointer dereference for 40nm PHYs?
The bcm7xxx_suspend() function is used as the suspend callback for PHY
models defined by the BCM7XXX_40NM_EPHY() macro (like BCM7346, BCM7362,
and BCM7425).
Unlike the 28nm and 16nm PHY macros which assign a probe callback to
allocate phydev->priv, the BCM7XXX_40NM_EPHY() macro does not appear to
define a probe callback. This would leave phydev->priv as NULL and cause a
crash when trying to access priv->stats here.
> + mutex_unlock(&phydev->lock);
>
> for (i = 0; i < ARRAY_SIZE(bcm7xxx_suspend_cfg); i++) {
> ret = phy_write(phydev,
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net 11/11] ice: add dpll peer notification for paired SMA and U.FL pins
From: Jacob Keller @ 2026-04-29 23:28 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Aleksandr Loktionov,
Simon Horman, Jiri Pirko
Cc: netdev, Petr Oros, Alexander Nowlin, Arkadiusz Kubalewski
In-Reply-To: <20260427-jk-iwl-net-petr-oros-fixes-v1-11-cdcb48303fd8@intel.com>
On 4/27/2026 10:22 PM, Jacob Keller wrote:
> From: Petr Oros <poros@redhat.com>
>
> SMA and U.FL pins share physical signal paths in pairs (SMA1/U.FL1 and
> SMA2/U.FL2). When one pin's state changes via a PCA9575 GPIO write,
> the paired pin's state also changes, but no notification is sent for
> the peer pin. Userspace consumers monitoring the peer via dpll netlink
> subscribe never learn about the update.
>
> Add ice_dpll_sw_pin_notify_peer() which sends a change notification for
> the paired SW pin. Call it from ice_dpll_pin_sma_direction_set(),
> ice_dpll_sma_pin_state_set(), and ice_dpll_ufl_pin_state_set() after
> pf->dplls.lock is released. Use __dpll_pin_change_ntf() because
> dpll_lock is still held by the dpll netlink layer (dpll_pin_pre_doit).
>
> Fixes: 2dd5d03c77e2 ("ice: redesign dpll sma/u.fl pins control")
> Signed-off-by: Petr Oros <poros@redhat.com>
> Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
> Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
Sashiko.dev says the following:
> commit f5e294c42ef0c3cf4bca4497a268b68f562bce96
> Author: Petr Oros <poros@redhat.com>
> ice: add dpll peer notification for paired SMA and U.FL pins
> SMA and U.FL pins share physical signal paths in pairs. This patch adds
> ice_dpll_sw_pin_notify_peer() to send a change notification for the
> paired SW pin when its state changes.
>> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
>> --- a/drivers/net/ethernet/intel/ice/ice_dpll.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
> [ ... ]
>> @@ -1344,6 +1370,8 @@ ice_dpll_ufl_pin_state_set(const struct dpll_pin *pin, void *pin_priv,
>>
>> unlock:
>> mutex_unlock(&pf->dplls.lock);
>> + if (!ret)
>> + ice_dpll_sw_pin_notify_peer(&pf->dplls, p);
> Could the hardware routing state become permanently out of sync with the
> userspace view if an error occurs here?
> While this patch doesn't introduce the underlying behavior, if enabling or
> disabling the backing CGU pin via ice_dpll_pin_enable() or
> ice_dpll_pin_disable() fails earlier in this function, an error is returned
> without rolling back the successful SMA control register write in
> ice_write_sma_ctrl().
> Since ret is non-zero on this error path, the ice_dpll_sw_pin_notify_peer()
> call is skipped, and the DPLL netlink core suppresses the change notification
> for the original pin.
> Does this leave the hardware state irreversibly altered while userspace
> receives an error, assumes no change occurred, and receives no notifications?
> This same question applies to ice_dpll_sma_pin_state_set() below.
>>
This reads to me like there is a possible issue in the existing code
which is separate from the issues this tries to address.
It looks like ice_dpll_pin_enable() can fail if the associated AdminQ
command fails. If we want to cleanly handle this, we likely need
unrolling logic which I think is an independent fix from anything in
this series.
I'm not sure what that unrolling logic would look like though. Maybe we
just need to undo the ice_write_sma_ctrl? But that also looks like an
AdminQ command we have to send.
I'm not sure how careful we need to be here in this flow.
Either way, to my eyes this looks like a pre-existing issue that may
need some attention but I don't feel like it should block these fixes.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH net-next] selftests/net: packetdrill: add tcp_syncookies_ip6_9k
From: Jakub Kicinski @ 2026-04-29 23:33 UTC (permalink / raw)
To: Neal Cardwell, Eric Dumazet
Cc: David S . Miller, Paolo Abeni, Simon Horman, Kuniyuki Iwashima,
netdev, eric.dumazet
In-Reply-To: <CADVnQyn-U-QgyT-HqeqZVX3FJi-UCgwfGJk2VaBBhjajKoih6g@mail.gmail.com>
On Wed, 29 Apr 2026 16:47:14 -0400 Neal Cardwell wrote:
> > diff --git a/gtests/net/packetdrill/code.c b/gtests/net/packetdrill/code.c
> > index d90bffabcfe6..6d8d20e64d8c 100644
> > --- a/gtests/net/packetdrill/code.c
> > +++ b/gtests/net/packetdrill/code.c
> > @@ -129,6 +129,7 @@ static void write_symbols(struct code_state *code)
> > emit_var(code, "TCPI_OPT_WSCALE", TCPI_OPT_WSCALE);
> > emit_var(code, "TCPI_OPT_ECN", TCPI_OPT_ECN);
> > emit_var(code, "TCPI_OPT_SYN_DATA", TCPI_OPT_SYN_DATA);
> > + emit_var(code, "TCPI_OPT_SACK", TCPI_OPT_SACK);
> > #endif /* linux */
> > }
>
> Sure! Done. I added all the missing bit values in the following commit:
>
> https://github.com/google/packetdrill/commit/faa0dfb54065118625e169d3111ce09c65b20229
>
> This can be picked up with the following, or similar:
>
> git clone https://github.com/google/packetdrill.git
Updated in netdev CI.
^ permalink raw reply
* [PATCH net] rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
From: Hyunwoo Kim @ 2026-04-29 23:35 UTC (permalink / raw)
To: dhowells, marc.dionne, davem, edumazet, kuba, pabeni, horms,
linux-afs, netdev
Cc: imv4bel
The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE
handler in rxrpc_verify_response() copy the skb to a linear one before
calling into the security ops only when skb_cloned() is true. An skb
that is not cloned but still carries paged fragments (skb->data_len != 0)
falls through to the in-place decryption path, which binds the frag
pages directly into the AEAD/skcipher SGL via skb_to_sgvec().
Extend the gate so that any skb with non-linear data is also copied,
ensuring the security handler always operates on a fully linear skb.
The OOM/trace handling already in place is reused.
Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
net/rxrpc/call_event.c | 2 +-
net/rxrpc/conn_event.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c
index fdd683261226..6c924ef55208 100644
--- a/net/rxrpc/call_event.c
+++ b/net/rxrpc/call_event.c
@@ -334,7 +334,7 @@ bool rxrpc_input_call_event(struct rxrpc_call *call)
if (sp->hdr.type == RXRPC_PACKET_TYPE_DATA &&
sp->hdr.securityIndex != 0 &&
- skb_cloned(skb)) {
+ (skb_cloned(skb) || skb->data_len)) {
/* Unshare the packet so that it can be
* modified by in-place decryption.
*/
diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c
index a2130d25aaa9..eab7c5f2517a 100644
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@ -245,7 +245,7 @@ static int rxrpc_verify_response(struct rxrpc_connection *conn,
{
int ret;
- if (skb_cloned(skb)) {
+ if (skb_cloned(skb) || skb->data_len) {
/* Copy the packet if shared so that we can do in-place
* decryption.
*/
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v4] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Jakub Kicinski @ 2026-04-29 23:46 UTC (permalink / raw)
To: daniel
Cc: Jakub Kicinski, chester.a.unal, andrew, olteanv, davem, edumazet,
pabeni, matthias.bgg, angelogioacchino.delregno, linux,
ansuelsmth, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <16efd278e4f17776ccfbf8491e5be71a4689c137.1777385305.git.daniel@makrotopia.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
This commit introduces a delayed workqueue to asynchronously poll MIB counters
for MDIO-connected switches. This caches the results so they can be returned
safely without sleeping in the atomic .get_stats64 callback.
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index b9423389c2ef..66bff861a921 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
[ ... ]
> @@ -3137,9 +3187,25 @@ mt753x_setup(struct dsa_switch *ds)
> if (ret && priv->irq_domain)
> mt7530_free_mdio_irq(priv);
>
> + if (!ret && priv->bus) {
> + spin_lock_init(&priv->stats_lock);
> + INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
> + mt7530_stats_refresh(priv);
> + schedule_delayed_work(&priv->stats_work,
> + MT7530_STATS_POLL_INTERVAL);
> + }
> +
> return ret;
> }
[ ... ]
> @@ -3409,6 +3476,9 @@ mt7530_remove_common(struct mt7530_priv *priv)
>
> dsa_unregister_switch(priv->ds);
>
> + if (priv->bus)
> + cancel_delayed_work_sync(&priv->stats_work);
Could this call cancel_delayed_work_sync() on an uninitialized work struct
if the driver is unbound before the DSA switch tree completes?
The priv->bus pointer is initialized during probe. However,
INIT_DELAYED_WORK() is only called in mt753x_setup(), which might never
execute if the DSA tree remains incomplete.
If the driver is unbound in this state, mt7530_remove_common() will evaluate
priv->bus as true and pass a zero-initialized work struct to
cancel_delayed_work_sync(). This usually triggers lockdep ("trying to
register non-static key") and debugobjects ("assert_init not available")
warnings.
Would it be better to move the INIT_DELAYED_WORK() call into the probe
path or track whether the setup function was actually completed?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: Unify user-visible "Qualcomm" name
From: patchwork-bot+netdevbpf @ 2026-04-29 23:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, loic.poulain,
ryazanov.s.a, johannes, netdev, linux-kernel, andersson,
konradybcio, linux-arm-msm
In-Reply-To: <20260427070127.18471-2-krzysztof.kozlowski@oss.qualcomm.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 09:01:27 +0200 you wrote:
> Various names for Qualcomm as a company are used in user-visible config
> options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
> "Qualcomm" so it will be easier for users to identify the options when
> for example running menuconfig.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> [...]
Here is the summary with links:
- net: Unify user-visible "Qualcomm" name
https://git.kernel.org/netdev/net-next/c/f48bf6145116
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v4] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-29 23:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: chester.a.unal, andrew, olteanv, davem, edumazet, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, ansuelsmth,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260429234612.2240476-2-kuba@kernel.org>
On Wed, Apr 29, 2026 at 04:46:13PM -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
>
> This commit introduces a delayed workqueue to asynchronously poll MIB counters
> for MDIO-connected switches. This caches the results so they can be returned
> safely without sleeping in the atomic .get_stats64 callback.
>
> > diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> > index b9423389c2ef..66bff861a921 100644
> > --- a/drivers/net/dsa/mt7530.c
> > +++ b/drivers/net/dsa/mt7530.c
>
> [ ... ]
>
> > @@ -3137,9 +3187,25 @@ mt753x_setup(struct dsa_switch *ds)
> > if (ret && priv->irq_domain)
> > mt7530_free_mdio_irq(priv);
> >
> > + if (!ret && priv->bus) {
> > + spin_lock_init(&priv->stats_lock);
> > + INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
> > + mt7530_stats_refresh(priv);
> > + schedule_delayed_work(&priv->stats_work,
> > + MT7530_STATS_POLL_INTERVAL);
> > + }
> > +
> > return ret;
> > }
>
> [ ... ]
>
> > @@ -3409,6 +3476,9 @@ mt7530_remove_common(struct mt7530_priv *priv)
> >
> > dsa_unregister_switch(priv->ds);
> >
> > + if (priv->bus)
> > + cancel_delayed_work_sync(&priv->stats_work);
>
> Could this call cancel_delayed_work_sync() on an uninitialized work struct
> if the driver is unbound before the DSA switch tree completes?
>
> The priv->bus pointer is initialized during probe. However,
> INIT_DELAYED_WORK() is only called in mt753x_setup(), which might never
> execute if the DSA tree remains incomplete.
>
> If the driver is unbound in this state, mt7530_remove_common() will evaluate
> priv->bus as true and pass a zero-initialized work struct to
> cancel_delayed_work_sync(). This usually triggers lockdep ("trying to
> register non-static key") and debugobjects ("assert_init not available")
> warnings.
>
> Would it be better to move the INIT_DELAYED_WORK() call into the probe
> path or track whether the setup function was actually completed?
Not sure if this is real. The fix could be simply
if (priv->bus && priv->ds->setup)
cancel_delayed_work_sync(&priv->stats_work);
Anyone?
^ permalink raw reply
* Re: [PATCH net v4] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Jakub Kicinski @ 2026-04-30 0:11 UTC (permalink / raw)
To: Daniel Golle
Cc: chester.a.unal, andrew, olteanv, davem, edumazet, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, ansuelsmth,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <afKaVQ27GUQiWZTb@makrotopia.org>
On Thu, 30 Apr 2026 00:55:01 +0100 Daniel Golle wrote:
> > > @@ -3409,6 +3476,9 @@ mt7530_remove_common(struct mt7530_priv *priv)
> > >
> > > dsa_unregister_switch(priv->ds);
> > >
> > > + if (priv->bus)
> > > + cancel_delayed_work_sync(&priv->stats_work);
> >
> > Could this call cancel_delayed_work_sync() on an uninitialized work struct
> > if the driver is unbound before the DSA switch tree completes?
> >
> > The priv->bus pointer is initialized during probe. However,
> > INIT_DELAYED_WORK() is only called in mt753x_setup(), which might never
> > execute if the DSA tree remains incomplete.
> >
> > If the driver is unbound in this state, mt7530_remove_common() will evaluate
> > priv->bus as true and pass a zero-initialized work struct to
> > cancel_delayed_work_sync(). This usually triggers lockdep ("trying to
> > register non-static key") and debugobjects ("assert_init not available")
> > warnings.
> >
> > Would it be better to move the INIT_DELAYED_WORK() call into the probe
> > path or track whether the setup function was actually completed?
>
> Not sure if this is real. The fix could be simply
>
> if (priv->bus && priv->ds->setup)
> cancel_delayed_work_sync(&priv->stats_work);
>
> Anyone?
Not sure how much of the D in DSA is actually implemented but in terms
of fix why not do what the bot suggests?
^ permalink raw reply
* Re: [PATCH net v4] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Andrew Lunn @ 2026-04-30 0:12 UTC (permalink / raw)
To: Daniel Golle
Cc: Jakub Kicinski, chester.a.unal, olteanv, davem, edumazet, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, ansuelsmth,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <afKaVQ27GUQiWZTb@makrotopia.org>
> > The priv->bus pointer is initialized during probe. However,
> > INIT_DELAYED_WORK() is only called in mt753x_setup(), which might never
> > execute if the DSA tree remains incomplete.
The opposite of .setup() is .teardown(). So if the delayed work is
setup is setup() it should be cancelled in .teardown, to keeps things
symmetric.
Andrew
^ permalink raw reply
* Re: [PATCH net v4] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Andrew Lunn @ 2026-04-30 0:13 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Golle, chester.a.unal, olteanv, davem, edumazet, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, ansuelsmth,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260429171124.07787599@kernel.org>
> Not sure how much of the D in DSA is actually implemented but in terms
> of fix why not do what the bot suggests?
As far as i know, this device is not D in DSA capable.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3] net: phy: realtek: support MDI swapping for RTL8226-CG
From: Andrew Lunn @ 2026-04-30 0:18 UTC (permalink / raw)
To: Jan Hoffmann
Cc: Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Daniel Golle, Markus Stockhausen,
Damien Dejean, netdev, linux-kernel
In-Reply-To: <20260429211235.2607782-1-jan@3e8.eu>
> + if (!swap_enable) {
> + /* Patching is only implemented one-way, see next comment. */
> + phydev_warn(phydev, "MDI swapping disabled, but PHY is already patched.\n");
> + return -EINVAL;
> + }
This appears to cause the probe to fail? If so, it should really be
phydev_err().
Otherwise this looks O.K.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] net: add net_iov_init() and use it to initialize ->page_type
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms,
asml.silence, axboe, almasrymina, sdf, hawk, akpm, rppt, vbabka,
io-uring
In-Reply-To: <20260428025320.853452-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 19:53:20 -0700 you wrote:
> Commit db359fccf212 ("mm: introduce a new page type for page pool in
> page type") added a page_type field to struct net_iov at the same
> offset as struct page::page_type, so that page_pool_set_pp_info() can
> call __SetPageNetpp() uniformly on both pages and net_iovs.
>
> The page-type API requires the field to hold the UINT_MAX "no type"
> sentinel before a type can be set; for real struct page that invariant
> is established by the page allocator on free. struct net_iov is not
> allocated through the page allocator, so the field is left as zero
> (io_uring zcrx, which uses __GFP_ZERO) or as slab garbage (devmem,
> which uses kvmalloc_objs() without zeroing). When the page pool then
> calls page_pool_set_pp_info() on a freshly-bound niov,
> __SetPageNetpp()'s VM_BUG_ON_PAGE(page->page_type != UINT_MAX) fires
> and the kernel BUGs. Triggered in selftests by io_uring zcrx setup
> through the fbnic queue restart path:
>
> [...]
Here is the summary with links:
- [net] net: add net_iov_init() and use it to initialize ->page_type
https://git.kernel.org/netdev/net/c/735a309b4bfb
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] MAINTAINERS: update the IPv4/IPv6 entry and add Ido Schimmel
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, dsahern,
idosch
In-Reply-To: <20260428203924.1229169-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 13:39:24 -0700 you wrote:
> The IPv4/IPv6 and routing code is not very well separated from
> the TCP/UDP code. Scope it down properly by providing a more
> accurate file list, instead of net/ipv4/ and net/ipv6/
>
> Now that the entry is more accurately representing layer 3
> and routing merge in the nexthop entry into it.
>
> [...]
Here is the summary with links:
- [net] MAINTAINERS: update the IPv4/IPv6 entry and add Ido Schimmel
https://git.kernel.org/netdev/net/c/e73cafaf4ace
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] selftests: drv-net: clarify linters and frameworks in README
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, shuah,
linux-kselftest
In-Reply-To: <20260428203357.1222611-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 13:33:57 -0700 you wrote:
> Minor clarifications in the README:
> - call out what linters we expect to be clean
> - make it clear that by "frameworks" we mean code under lib/
> not just factoring code out in the same file
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> [...]
Here is the summary with links:
- [net-next] selftests: drv-net: clarify linters and frameworks in README
https://git.kernel.org/netdev/net/c/72e9647e2b20
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: psp: add more validation
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms,
willemdebruijn.kernel, daniel.zahka
In-Reply-To: <20260428205352.1247325-1-kuba@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 13:53:49 -0700 you wrote:
> Address some AI code-scan issues with the PSP code.
> I don't think any of these are real bugs, but they may
> become bugs in the future. The two real bugs discovered
> were posted separately for net. AI reports 3 more which
> seem plain wrong (rx SPI "leak" on error etc.).
>
> Jakub Kicinski (3):
> psp: validate protocol before mutating skb in psp_dev_encapsulate()
> psp: add a comment about a psp_dev add netlink notification
> psp: validate IPv4 header fields in psp_dev_rcv()
>
> [...]
Here is the summary with links:
- [net-next,1/3] psp: validate protocol before mutating skb in psp_dev_encapsulate()
https://git.kernel.org/netdev/net-next/c/28e71cb51cdf
- [net-next,2/3] psp: add a comment about a psp_dev add netlink notification
https://git.kernel.org/netdev/net-next/c/5637fcb11c91
- [net-next,3/3] psp: validate IPv4 header fields in psp_dev_rcv()
https://git.kernel.org/netdev/net-next/c/c2b22277ad89
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: phy: aquantia: use ADVERTISE_XNP for extended next page advertising
From: patchwork-bot+netdevbpf @ 2026-04-30 0:40 UTC (permalink / raw)
To: Maxime Chevallier
Cc: andrew, kuba, davem, edumazet, pabeni, horms, linux, hkallweit1,
vladimir.oltean, camelia.groza, thomas.petazzoni, netdev,
linux-kernel
In-Reply-To: <20260428125827.238469-1-maxime.chevallier@bootlin.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 14:58:27 +0200 you wrote:
> When configuring the link parameters in forced mode for the AQR-105, the
> Extended Next Page bit gets advertised for Multi-Gigabit modes.
>
> This is done through bit 12 of MDIO_AN_ADVERTISE in MDIO_MMD_AN. This
> contains a copy of the MII_ADVERTISE, for which 802.3 defines bit 12 as
> the Extended Next Page advertising. This bit used to be marked as
> reserved, but a proper define for it was added in :
>
> [...]
Here is the summary with links:
- [net-next] net: phy: aquantia: use ADVERTISE_XNP for extended next page advertising
https://git.kernel.org/netdev/net-next/c/e2d217fe3ff2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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