From: Vladimir Oltean <olteanv@gmail.com>
To: Wei Fang <wei.fang@nxp.com>
Cc: claudiu.manoil@nxp.com, vladimir.oltean@nxp.com,
xiaoning.wang@nxp.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, christophe.leroy@csgroup.eu,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 net-next 02/14] net: enetc: add command BD ring support for i.MX95 ENETC
Date: Fri, 18 Apr 2025 16:25:11 +0300 [thread overview]
Message-ID: <20250418132511.azibvntwzh6odqvx@skbuf> (raw)
In-Reply-To: <20250411095752.3072696-3-wei.fang@nxp.com> <20250411095752.3072696-3-wei.fang@nxp.com>
On Fri, Apr 11, 2025 at 05:57:40PM +0800, Wei Fang wrote:
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c b/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c
> index 20bfdf7fb4b4..ecb571e5ea50 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_cbdr.c
> @@ -60,6 +60,45 @@ void enetc_teardown_cbdr(struct enetc_cbdr *cbdr)
> }
> EXPORT_SYMBOL_GPL(enetc_teardown_cbdr);
>
> +int enetc4_setup_cbdr(struct enetc_si *si)
> +{
> + struct ntmp_user *user = &si->ntmp_user;
> + struct device *dev = &si->pdev->dev;
> + struct enetc_hw *hw = &si->hw;
> + struct netc_cbdr_regs regs;
> +
> + user->cbdr_num = 1;
> + user->cbdr_size = NETC_CBDR_BD_NUM;
> + user->dev = dev;
> + user->ring = devm_kcalloc(dev, user->cbdr_num,
> + sizeof(struct netc_cbdr), GFP_KERNEL);
> + if (!user->ring)
> + return -ENOMEM;
> +
> + /* set CBDR cache attributes */
> + enetc_wr(hw, ENETC_SICAR2,
> + ENETC_SICAR_RD_COHERENT | ENETC_SICAR_WR_COHERENT);
> +
> + regs.pir = hw->reg + ENETC_SICBDRPIR;
> + regs.cir = hw->reg + ENETC_SICBDRCIR;
> + regs.mr = hw->reg + ENETC_SICBDRMR;
> + regs.bar0 = hw->reg + ENETC_SICBDRBAR0;
> + regs.bar1 = hw->reg + ENETC_SICBDRBAR1;
> + regs.lenr = hw->reg + ENETC_SICBDRLENR;
> +
> + return netc_setup_cbdr(dev, user->cbdr_size, ®s, user->ring);
> +}
> +EXPORT_SYMBOL_GPL(enetc4_setup_cbdr);
> +
> +void enetc4_teardown_cbdr(struct enetc_si *si)
> +{
> + struct ntmp_user *user = &si->ntmp_user;
> +
> + netc_teardown_cbdr(user->dev, user->ring);
> + user->dev = NULL;
> +}
> +EXPORT_SYMBOL_GPL(enetc4_teardown_cbdr);
I wanted to ask why isn't netc_setup_cbdr() merged into enetc4_setup_cbdr()
(and likewise for teardown_cbdr), because they sound very similar, and
they operate on the same data - one is literally a continuation of the
other. Then I looked downstream where the netc_switch is another API
user of netc_setup_cbdr() and netc_teardown_cbdr().
Do you think you could rename netc_setup_cbdr() into something like below:
struct ntmp_user *ntmp_user_create(struct device *dev, size_t num_cbdr,
const struct netc_cbdr_regs *regs);
void ntmp_user_destroy(struct ntmp_user *user);
From a data encapsulation perspective, it would be great if the outside
world only worked with an opaque struct ntmp_user * pointer.
Hide NETC_CBDR_BD_NUM from include/linux/fsl/ntmp.h if API users don't
need to customize it, and let ntmp_user_create() set it.
Move even more initialization into ntmp_user_create(), like the
allocation of "user->ring", and reduce the number of arguments.
In my opinion this would be a more natural organization of the code.
next prev parent reply other threads:[~2025-04-18 13:28 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-11 9:57 [PATCH v5 net-next 00/14] Add more features for ENETC v4 - round 2 Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 01/14] net: enetc: add initial netc-lib driver to support NTMP Wei Fang
2025-04-18 12:49 ` Vladimir Oltean
2025-04-18 13:38 ` Wei Fang
2025-04-18 13:49 ` Vladimir Oltean
2025-04-11 9:57 ` [PATCH v5 net-next 02/14] net: enetc: add command BD ring support for i.MX95 ENETC Wei Fang
2025-04-18 13:25 ` Vladimir Oltean [this message]
2025-04-18 13:49 ` Wei Fang
2025-04-18 13:52 ` Vladimir Oltean
2025-04-11 9:57 ` [PATCH v5 net-next 03/14] net: enetc: move generic MAC filtering interfaces to enetc-core Wei Fang
2025-04-18 13:37 ` Vladimir Oltean
2025-04-11 9:57 ` [PATCH v5 net-next 04/14] net: enetc: add MAC filtering for i.MX95 ENETC PF Wei Fang
2025-04-16 3:42 ` Jakub Kicinski
2025-04-16 5:16 ` Wei Fang
2025-04-18 14:29 ` Vladimir Oltean
2025-04-18 15:41 ` Vladimir Oltean
2025-04-21 3:14 ` Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 05/14] net: enetc: add debugfs interface to dump MAC filter Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 06/14] net: enetc: add set/get_rss_table() hooks to enetc_si_ops Wei Fang
2025-04-15 13:43 ` Paolo Abeni
2025-04-16 2:31 ` Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 07/14] net: enetc: make enetc_set_rss_key() reusable Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 08/14] net: enetc: add RSS support for i.MX95 ENETC PF Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 09/14] net: enetc: change enetc_set_rss() to void type Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 10/14] net: enetc: enable RSS feature by default Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 11/14] net: enetc: extract enetc_refresh_vlan_ht_filter() Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 12/14] net: enetc: move generic VLAN hash filter functions to enetc_pf_common.c Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 13/14] net: enetc: add VLAN filtering support for i.MX95 ENETC PF Wei Fang
2025-04-11 9:57 ` [PATCH v5 net-next 14/14] net: enetc: add loopback " Wei Fang
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=20250418132511.azibvntwzh6odqvx@skbuf \
--to=olteanv@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=christophe.leroy@csgroup.eu \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vladimir.oltean@nxp.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.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