netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Boon Khai Ng <boon.khai.ng@altera.com>
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	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>,
	Russell King <linux@armlinux.org.uk>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Furong Xu <0x1207@gmail.com>,
	Matthew Gerlach <matthew.gerlach@altera.com>,
	Tien Sung Ang <tien.sung.ang@altera.com>,
	Mun Yew Tham <mun.yew.tham@altera.com>,
	G Thomas Rohan <rohan.g.thomas@altera.com>
Subject: Re: [PATCH net-next v4 1/2] net: stmmac: Refactor VLAN implementation
Date: Thu, 24 Apr 2025 13:16:04 +0100	[thread overview]
Message-ID: <20250424121604.GE3042781@horms.kernel.org> (raw)
In-Reply-To: <20250421162930.10237-2-boon.khai.ng@altera.com>

On Tue, Apr 22, 2025 at 12:29:29AM +0800, Boon Khai Ng wrote:
> Refactor VLAN implementation by moving common code for DWMAC4 and
> DWXGMAC IPs into a separate VLAN module. VLAN implementation for
> DWMAC4 and DWXGMAC differs only for CSR base address, the descriptor
> for the VLAN ID and VLAN VALID bit field.
> 
> The descriptor format for VLAN is not moved to the common code due
> to hardware-specific differences between DWMAC4 and DWXGMAC.
> 
> For the DWMAC4 IP, the Receive Normal Descriptor 0 (RDES0) is
> formatted as follows:
>     31                                                0
>       ------------------------ -----------------------
> RDES0| Inner VLAN TAG [31:16] | Outer VLAN TAG [15:0] |
>       ------------------------ -----------------------
> 
> For the DWXGMAC IP, the RDES0 format varies based on the
> Tunneled Frame bit (TNP):
> 
> a) For Non-Tunneled Frame (TNP=0)
> 
>     31                                                0
>       ------------------------ -----------------------
> RDES0| Inner VLAN TAG [31:16] | Outer VLAN TAG [15:0] |
>       ------------------------ -----------------------
> 
> b) For Tunneled Frame (TNP=1)
> 
>      31                   8 7                3 2      0
>       --------------------- ------------------ -------
> RDES0| VNID/VSID           | Reserved         | OL2L3 |
>       --------------------- ------------------ ------
> 
> The logic for handling tunneled frames is not yet implemented
> in the dwxgmac2_wrback_get_rx_vlan_tci() function. Therefore,
> it is prudent to maintain separate functions within their
> respective descriptor driver files
> (dwxgmac2_descs.c and dwmac4_descs.c).
> 
> Signed-off-by: Boon Khai Ng <boon.khai.ng@altera.com>
> Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com>

...

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> index a6d395c6bacd..d9f41c047e5e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> @@ -614,76 +614,6 @@ static int dwxgmac2_rss_configure(struct mac_device_info *hw,
>  	return 0;
>  }
>  
> -static void dwxgmac2_update_vlan_hash(struct mac_device_info *hw, u32 hash,
> -				      u16 perfect_match, bool is_double)
> -{
> -	void __iomem *ioaddr = hw->pcsr;
> -
> -	writel(hash, ioaddr + XGMAC_VLAN_HASH_TABLE);
> -
> -	if (hash) {
> -		u32 value = readl(ioaddr + XGMAC_PACKET_FILTER);
> -
> -		value |= XGMAC_FILTER_VTFE;
> -
> -		writel(value, ioaddr + XGMAC_PACKET_FILTER);

Here the XGMAC_FILTER_VTFE bit of XGMAC_PACKET_FILTER is set.
However, this logic does not appear in vlan_update_hash()

> -
> -		value = readl(ioaddr + XGMAC_VLAN_TAG);
> -
> -		value |= XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV;
> -		if (is_double) {
> -			value |= XGMAC_VLAN_EDVLP;
> -			value |= XGMAC_VLAN_ESVL;
> -			value |= XGMAC_VLAN_DOVLTC;
> -		} else {
> -			value &= ~XGMAC_VLAN_EDVLP;
> -			value &= ~XGMAC_VLAN_ESVL;
> -			value &= ~XGMAC_VLAN_DOVLTC;
> -		}

And likewise, here value is based on reading from XGMAC_VLAN_TAG.
Whereas in vlan_update_hash is constructed without reading from
XGMAC_VLAN_TAG.

Can I clarify that this is intentional and that vlan_update_hash(),
which is based on the DWMAC4 implementation, will also work for DWXGMAC IP?

> -
> -		value &= ~XGMAC_VLAN_VID;
> -		writel(value, ioaddr + XGMAC_VLAN_TAG);
> -	} else if (perfect_match) {
> -		u32 value = readl(ioaddr + XGMAC_PACKET_FILTER);
> -
> -		value |= XGMAC_FILTER_VTFE;
> -
> -		writel(value, ioaddr + XGMAC_PACKET_FILTER);
> -
> -		value = readl(ioaddr + XGMAC_VLAN_TAG);
> -
> -		value &= ~XGMAC_VLAN_VTHM;
> -		value |= XGMAC_VLAN_ETV;
> -		if (is_double) {
> -			value |= XGMAC_VLAN_EDVLP;
> -			value |= XGMAC_VLAN_ESVL;
> -			value |= XGMAC_VLAN_DOVLTC;
> -		} else {
> -			value &= ~XGMAC_VLAN_EDVLP;
> -			value &= ~XGMAC_VLAN_ESVL;
> -			value &= ~XGMAC_VLAN_DOVLTC;
> -		}
> -
> -		value &= ~XGMAC_VLAN_VID;
> -		writel(value | perfect_match, ioaddr + XGMAC_VLAN_TAG);
> -	} else {
> -		u32 value = readl(ioaddr + XGMAC_PACKET_FILTER);
> -
> -		value &= ~XGMAC_FILTER_VTFE;
> -
> -		writel(value, ioaddr + XGMAC_PACKET_FILTER);
> -
> -		value = readl(ioaddr + XGMAC_VLAN_TAG);
> -
> -		value &= ~(XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV);
> -		value &= ~(XGMAC_VLAN_EDVLP | XGMAC_VLAN_ESVL);
> -		value &= ~XGMAC_VLAN_DOVLTC;
> -		value &= ~XGMAC_VLAN_VID;
> -
> -		writel(value, ioaddr + XGMAC_VLAN_TAG);
> -	}
> -}

...

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c

...

> +static int vlan_write_filter(struct net_device *dev,
> +			     struct mac_device_info *hw,
> +			     u8 index, u32 data)
> +{
> +	void __iomem *ioaddr = (void __iomem *)dev->base_addr;
> +	int i, timeout = 10;
> +	u32 val;
> +
> +	if (index >= hw->num_vlan)
> +		return -EINVAL;
> +
> +	writel(data, ioaddr + VLAN_TAG_DATA);
> +
> +	val = readl(ioaddr + VLAN_TAG);
> +	val &= ~(VLAN_TAG_CTRL_OFS_MASK |
> +		VLAN_TAG_CTRL_CT |
> +		VLAN_TAG_CTRL_OB);
> +	val |= (index << VLAN_TAG_CTRL_OFS_SHIFT) | VLAN_TAG_CTRL_OB;
> +
> +	writel(val, ioaddr + VLAN_TAG);
> +
> +	for (i = 0; i < timeout; i++) {
> +		val = readl(ioaddr + VLAN_TAG);
> +		if (!(val & VLAN_TAG_CTRL_OB))
> +			return 0;
> +		udelay(1);
> +	}

I am curious to know why readl_poll_timeout() isn't used here
as was the case in dwmac4_write_vlan_filter().

> +
> +	netdev_err(dev, "Timeout accessing MAC_VLAN_Tag_Filter\n");
> +
> +	return -EBUSY;
> +}

...

  parent reply	other threads:[~2025-04-24 12:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-21 16:29 [PATCH net-next v4 0/2] Refactoring designware VLAN code Boon Khai Ng
2025-04-21 16:29 ` [PATCH net-next v4 1/2] net: stmmac: Refactor VLAN implementation Boon Khai Ng
2025-04-24 12:04   ` Paolo Abeni
2025-04-24 12:32     ` Russell King (Oracle)
2025-04-25  7:12       ` Ng, Boon Khai
2025-04-25  7:08     ` Ng, Boon Khai
2025-04-24 12:16   ` Simon Horman [this message]
2025-04-28  8:34     ` Ng, Boon Khai
2025-04-21 16:29 ` [PATCH net-next v4 2/2] net: stmmac: dwxgmac2: Add support for HW-accelerated VLAN stripping Boon Khai Ng
2025-04-24 11:53   ` Paolo Abeni
2025-04-25  7:09     ` Ng, Boon Khai
2025-04-24 12:17   ` Simon Horman
2025-04-25  7:15     ` Ng, Boon Khai

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=20250424121604.GE3042781@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=0x1207@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=ast@kernel.org \
    --cc=boon.khai.ng@altera.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=john.fastabend@gmail.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=linux@armlinux.org.uk \
    --cc=matthew.gerlach@altera.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mun.yew.tham@altera.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rohan.g.thomas@altera.com \
    --cc=tien.sung.ang@altera.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;
as well as URLs for NNTP newsgroup(s).