From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Michal Piekos <michal.piekos@mmpsystems.pl>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] net: stmmac: skip VLAN restore when VLAN hash ops are missing
Date: Thu, 26 Mar 2026 08:49:20 +0100 [thread overview]
Message-ID: <abb1c779-b306-42f8-b2b1-aa56bfcebe1b@bootlin.com> (raw)
In-Reply-To: <20260321-vlan-restore-error-v2-1-45cf56a5223d@mmpsystems.pl>
Hi,
On 21/03/2026 06:38, Michal Piekos wrote:
> stmmac_vlan_restore() unconditionally calls stmmac_vlan_update() when
> NETIF_F_VLAN_FEATURES is set. On platforms where priv->hw->vlan (or
> ->update_vlan_hash) is not provided, stmmac_update_vlan_hash() returns
> -EINVAL via stmmac_do_void_callback(), resulting in a spurious
> "Failed to restore VLANs" error even when no VLAN filtering is in use.
>
> Check presence of VLAN HW FILTER flags before stmmac_vlan_update().
>
> Tested on Orange Pi Zero 3.
>
> Fixes: bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore")
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> This patch fixes a noisy "Failed to restore VLANs" message on platforms
> where stmmac VLAN hash ops are not implemented.
> stmmac_vlan_restore() calls stmmac_vlan_update() without checking for
> VLAN hash ops presence which results in -EINVAL.
I've been seeing the same message on socfpga. My two cents on that is
that this error messages doesn't bring anything to the table anyways.
As Russell explains, it's either triggered when the vlan op isn't
implemented (the stmmac callback macro stuff turns that into a -EINVAL),
or when some capabilities arent present. All in all, it's always stuff
that users can't really do anything about, as it's HW limitations, I
think we can simply discard this message.
Also, nothing actually checks what stmmac_vlan_restore() returns, so we
might as well return void ?
Maxime
> ---
> Changes in v2:
> - Replace check for hash ops with check for HW FILTER flags
> - Link to v1: https://lore.kernel.org/r/20260314-vlan-restore-error-v1-1-4fc6c3e2115f@mmpsystems.pl
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 6827c99bde8c..cfc0ce9cec9c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6863,7 +6863,8 @@ static int stmmac_vlan_restore(struct stmmac_priv *priv)
> {
> int ret;
>
> - if (!(priv->dev->features & NETIF_F_VLAN_FEATURES))
> + if (!(priv->dev->features &
> + (NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)))
> return 0;
>
> if (priv->hw->num_vlan)
>
> ---
> base-commit: 42bddab0563fe67882b2722620a66dd98c8dbf33
> change-id: 20260314-vlan-restore-error-f8b3a1c7f50a
>
> Best regards,
next prev parent reply other threads:[~2026-03-26 7:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 5:38 [PATCH v2] net: stmmac: skip VLAN restore when VLAN hash ops are missing Michal Piekos
2026-03-24 12:14 ` Paolo Abeni
2026-03-24 13:04 ` Russell King (Oracle)
2026-03-24 15:37 ` Ovidiu Panait
2026-03-24 15:59 ` Russell King (Oracle)
2026-03-26 7:49 ` Maxime Chevallier [this message]
2026-03-26 8:07 ` Ovidiu Panait
2026-03-26 11:14 ` Michal Piekos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abb1c779-b306-42f8-b2b1-aa56bfcebe1b@bootlin.com \
--to=maxime.chevallier@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=michal.piekos@mmpsystems.pl \
--cc=netdev@vger.kernel.org \
--cc=ovidiu.panait.rb@renesas.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox