All of lore.kernel.org
 help / color / mirror / Atom feed
From: Furong Xu <0x1207@gmail.com>
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>,
	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 v3 1/2] net: stmmac: Refactor VLAN implementation
Date: Thu, 10 Apr 2025 14:38:21 +0800	[thread overview]
Message-ID: <20250410143821.000002c0@gmail.com> (raw)
In-Reply-To: <20250408081354.25881-2-boon.khai.ng@altera.com>

On Tue,  8 Apr 2025 16:13:53 +0800, Boon Khai Ng <boon.khai.ng@altera.com> 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.
> 
> Signed-off-by: Boon Khai Ng <boon.khai.ng@altera.com>
> Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/Makefile  |   2 +-
>  drivers/net/ethernet/stmicro/stmmac/common.h  |   1 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |  40 ---
>  .../net/ethernet/stmicro/stmmac/dwmac4_core.c | 295 +-----------------
>  .../net/ethernet/stmicro/stmmac/dwxgmac2.h    |  13 -
>  .../ethernet/stmicro/stmmac/dwxgmac2_core.c   |  87 ------
>  drivers/net/ethernet/stmicro/stmmac/hwif.c    |   8 +
>  drivers/net/ethernet/stmicro/stmmac/hwif.h    |  61 ++--
>  .../net/ethernet/stmicro/stmmac/stmmac_vlan.c | 294 +++++++++++++++++
>  .../net/ethernet/stmicro/stmmac/stmmac_vlan.h |  63 ++++
>  10 files changed, 401 insertions(+), 463 deletions(-)
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.c
>  create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.h
> 
[...]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> index 31bdbab9a46c..0a57c5e7497d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> @@ -9,6 +9,7 @@
>  #include "stmmac_fpe.h"
>  #include "stmmac_ptp.h"
>  #include "stmmac_est.h"
> +#include "stmmac_vlan.h"
>  #include "dwmac4_descs.h"
>  #include "dwxgmac2.h"
>  
> @@ -120,6 +121,7 @@ static const struct stmmac_hwif_entry {
>  	const void *tc;
>  	const void *mmc;
>  	const void *est;
> +	const void *vlan;
>  	int (*setup)(struct stmmac_priv *priv);
>  	int (*quirks)(struct stmmac_priv *priv);
>  } stmmac_hw[] = {
> @@ -197,6 +199,7 @@ static const struct stmmac_hwif_entry {
>  		.desc = &dwmac4_desc_ops,
>  		.dma = &dwmac4_dma_ops,
>  		.mac = &dwmac410_ops,
> +		.vlan = &dwmac_vlan_ops,

Rename dwmac_vlan_ops to dwmac4_vlan_ops will be better,
just like dwmac4_desc_ops/dwmac4_dma_ops

[...]
> +const struct stmmac_vlan_ops dwmac_vlan_ops = {
> +	.update_vlan_hash = vlan_update_hash,
> +	.enable_vlan = vlan_enable,
> +	.add_hw_vlan_rx_fltr = vlan_add_hw_rx_fltr,
> +	.del_hw_vlan_rx_fltr = vlan_del_hw_rx_fltr,
> +	.restore_hw_vlan_rx_fltr = vlan_restore_hw_rx_fltr,
> +	.rx_hw_vlan = vlan_rx_hw,
> +	.set_hw_vlan_mode = vlan_set_hw_mode,
> +};
> +
> +const struct stmmac_vlan_ops dwxlgmac2_vlan_ops = {
> +	.update_vlan_hash = vlan_update_hash,
> +	.enable_vlan = vlan_enable,
> +};

dwxlgmac2_vlan_ops looks redundant here, another new struct contains
totally identical members.

stmmac_do_void_callback()/stmmac_do_callback() handles NULL function
pointers so good, we can leave the un-implemented functions as NULL.

Are you trying to avoid something undefined here?

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.h
> new file mode 100644
> index 000000000000..29e7be83161e
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_vlan.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2025, Altera Corporation
> + * stmmac VLAN(802.1Q) handling
> + */
> +
> +#ifndef __STMMAC_VLAN_H__
> +#define __STMMAC_VLAN_H__
> +
> +#include <linux/bitfield.h>
> +
> +#define VLAN_TAG			0x00000050
> +#define VLAN_TAG_DATA			0x00000054
> +#define VLAN_HASH_TABLE			0x00000058
> +#define VLAN_INCL			0x00000060
> +
> +#define HW_FEATURE3			0x00000128
> +
> +/* MAC VLAN */
> +#define VLAN_EDVLP			BIT(26)
> +#define VLAN_VTHM			BIT(25)
> +#define VLAN_DOVLTC			BIT(20)
> +#define VLAN_ESVL			BIT(18)
> +#define VLAN_ETV			BIT(16)
> +#define VLAN_VID			GENMASK(15, 0)
> +#define VLAN_VLTI			BIT(20)
> +#define VLAN_CSVL			BIT(19)
> +#define VLAN_VLC			GENMASK(17, 16)
> +#define VLAN_VLC_SHIFT			16
> +#define VLAN_VLHT			GENMASK(15, 0)
> +
> +/* MAC VLAN Tag */
> +#define VLAN_TAG_VID			GENMASK(15, 0)
> +#define VLAN_TAG_ETV			BIT(16)
> +
> +/* MAC VLAN Tag Control */
> +#define VLAN_TAG_CTRL_OB		BIT(0)
> +#define VLAN_TAG_CTRL_CT		BIT(1)
> +#define VLAN_TAG_CTRL_OFS_MASK		GENMASK(6, 2)
> +#define VLAN_TAG_CTRL_OFS_SHIFT		2
> +#define VLAN_TAG_CTRL_EVLS_MASK		GENMASK(22, 21)
> +#define VLAN_TAG_CTRL_EVLS_SHIFT	21
> +#define VLAN_TAG_CTRL_EVLRXS		BIT(24)
> +
> +#define VLAN_TAG_STRIP_NONE		FIELD_PREP(VLAN_TAG_CTRL_EVLS_MASK, 0x0)
> +#define VLAN_TAG_STRIP_PASS		FIELD_PREP(VLAN_TAG_CTRL_EVLS_MASK, 0x1)
> +#define VLAN_TAG_STRIP_FAIL		FIELD_PREP(VLAN_TAG_CTRL_EVLS_MASK, 0x2)
> +#define VLAN_TAG_STRIP_ALL		FIELD_PREP(VLAN_TAG_CTRL_EVLS_MASK, 0x3)
> +
> +/* MAC VLAN Tag Data/Filter */
> +#define VLAN_TAG_DATA_VID		GENMASK(15, 0)
> +#define VLAN_TAG_DATA_VEN		BIT(16)
> +#define VLAN_TAG_DATA_ETV		BIT(17)
> +
> +/* MAC VLAN HW FEAT */
> +#define VLAN_HW_FEAT_NRVF		GENMASK(2, 0)
> +
> +extern const struct stmmac_vlan_ops dwmac_vlan_ops;
> +extern const struct stmmac_vlan_ops dwxlgmac2_vlan_ops;
> +
> +u32 stmmac_get_num_vlan(void __iomem *ioaddr);
> +
> +#endif /* __STMMAC_VLAN_H__ */

It is a good practice to only keep inside the header those definitions
which are truly exported by stmmac_vlan.c towards external callers.
That means those #defines which are only used within stmmac_vlan.c
shouldn't be here, but inside stmmac_vlan.c file.

  reply	other threads:[~2025-04-10  6:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-08  8:13 [PATCH net-next v3 0/2] Refactoring designware VLAN code Boon Khai Ng
2025-04-08  8:13 ` [PATCH net-next v3 1/2] net: stmmac: Refactor VLAN implementation Boon Khai Ng
2025-04-10  6:38   ` Furong Xu [this message]
2025-04-21 16:40     ` Ng, Boon Khai
2025-04-10  8:19   ` Furong Xu
2025-04-11 16:27     ` Simon Horman
2025-04-21 16:52       ` Ng, Boon Khai
2025-04-11 16:36   ` Simon Horman
2025-04-21 16:47     ` Ng, Boon Khai
2025-04-08  8:13 ` [PATCH net-next v3 2/2] net: stmmac: dwxgmac2: Add support for HW-accelerated VLAN stripping Boon Khai Ng
2025-04-08 19:08   ` Andrew Lunn
2025-04-09  3:12     ` Ng, Boon Khai
2025-04-09 12:04       ` Andrew Lunn
2025-04-10  2:19         ` 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=20250410143821.000002c0@gmail.com \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.