public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Wei Fang <wei.fang@nxp.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, claudiu.manoil@nxp.com,
	xiaoning.wang@nxp.com, Frank.Li@nxp.com,
	christophe.leroy@csgroup.eu, linux@armlinux.org.uk,
	bhelgaas@google.com, horms@kernel.org, imx@lists.linux.dev,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	alexander.stein@ew.tq-group.com
Subject: Re: [PATCH v5 net-next 10/13] net: enetc: extract enetc_int_vector_init/destroy() from enetc_alloc_msix()
Date: Thu, 24 Oct 2024 23:50:13 +0300	[thread overview]
Message-ID: <20241024205013.xw72mtssgvmwfmuu@skbuf> (raw)
In-Reply-To: <20241024065328.521518-11-wei.fang@nxp.com>

On Thu, Oct 24, 2024 at 02:53:25PM +0800, Wei Fang wrote:
> From: Clark Wang <xiaoning.wang@nxp.com>
> 
> Extract enetc_int_vector_init() and enetc_int_vector_destroy() from
> enetc_alloc_msix() so that the code is more concise and readable. In
> addition, slightly different from before, the cleanup helper function
> is used to manage dynamically allocated memory resources.
> 
> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
> Signed-off-by: Wei Fang <wei.fang@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> v5: no changes
> ---
>  drivers/net/ethernet/freescale/enetc/enetc.c | 172 ++++++++++---------
>  1 file changed, 87 insertions(+), 85 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
> index 032d8eadd003..bd725561b8a2 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> @@ -2965,6 +2965,87 @@ int enetc_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd)
>  }
>  EXPORT_SYMBOL_GPL(enetc_ioctl);
>  
> +static int enetc_int_vector_init(struct enetc_ndev_priv *priv, int i,
> +				 int v_tx_rings)
> +{
> +	struct enetc_int_vector *v __free(kfree);

Please limit yourself to refactoring the code as-is into a separate function.
This function does not benefit in any way from the use of __free() and
no_free_ptr(). The established norm is that the normal teardown path
should be identical to the error unwind path, minus the last step.
Combining normal function calls with devres/scope-based cleanup/whatever
other "look, you don't get to care about error handling!!!" APIs there may be
makes that much more difficult to reason about. If the function is really
simple and you really don't get to care about error handling by using __free(),
then maybe its usage is tolerable, but that is hardly the general case.
The more intricate the error handling becomes, the less useful __free() is,
and the more it starts getting in the way of a human correctness reviewer.

FWIW, Documentation/process/maintainer-netdev.rst, section "Using
device-managed and cleanup.h constructs", appears to mostly state the
same position as me here.

Obviously, here, the established cleanup norm isn't followed anyway, but
a patch which brings it in line would be appreciated. I think that a
multi-patch approach, where the code is first moved and just moved, and
then successively transformed in obviously correct and easy to review
steps, would be best.

Since you're quite close currently to the 15-patch limit, I would try to
create a patch set just for preparing the enetc drivers, and introduce
the i.mx95 support in a separate set which has mostly "+" lines in its diff.
That way, there is also some time to not rush the ongoing IERB/PRB
dt-binding discussion, while you can progress on pure driver refactoring.

> +	struct enetc_bdr *bdr;
> +	int j, err;
> +
> +	v = kzalloc(struct_size(v, tx_ring, v_tx_rings), GFP_KERNEL);
> +	if (!v)
> +		return -ENOMEM;
> +
> +	bdr = &v->rx_ring;
> +	bdr->index = i;
> +	bdr->ndev = priv->ndev;
> +	bdr->dev = priv->dev;
> +	bdr->bd_count = priv->rx_bd_count;
> +	bdr->buffer_offset = ENETC_RXB_PAD;
> +	priv->rx_ring[i] = bdr;
> +
> +	err = xdp_rxq_info_reg(&bdr->xdp.rxq, priv->ndev, i, 0);
> +	if (err)
> +		return err;
> +
> +	err = xdp_rxq_info_reg_mem_model(&bdr->xdp.rxq,
> +					 MEM_TYPE_PAGE_SHARED, NULL);

MEM_TYPE_PAGE_SHARED fits on the previous line.

> +	if (err) {
> +		xdp_rxq_info_unreg(&bdr->xdp.rxq);
> +		return err;
> +	}
> +
> +	/* init defaults for adaptive IC */
> +	if (priv->ic_mode & ENETC_IC_RX_ADAPTIVE) {
> +		v->rx_ictt = 0x1;
> +		v->rx_dim_en = true;
> +	}
> +
> +	INIT_WORK(&v->rx_dim.work, enetc_rx_dim_work);
> +	netif_napi_add(priv->ndev, &v->napi, enetc_poll);
> +	v->count_tx_rings = v_tx_rings;
> +
> +	for (j = 0; j < v_tx_rings; j++) {
> +		int idx;
> +
> +		/* default tx ring mapping policy */
> +		idx = priv->bdr_int_num * j + i;
> +		__set_bit(idx, &v->tx_rings_map);
> +		bdr = &v->tx_ring[j];
> +		bdr->index = idx;
> +		bdr->ndev = priv->ndev;
> +		bdr->dev = priv->dev;
> +		bdr->bd_count = priv->tx_bd_count;
> +		priv->tx_ring[idx] = bdr;
> +	}
> +
> +	priv->int_vector[i] = no_free_ptr(v);
> +
> +	return 0;
> +}

  reply	other threads:[~2024-10-24 20:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24  6:53 [PATCH v5 net-next 00/13] add basic support for i.MX95 NETC Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 01/13] dt-bindings: net: add compatible string for i.MX95 EMDIO Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 02/13] dt-bindings: net: add i.MX95 ENETC support Wei Fang
2024-10-25 14:07   ` Rob Herring
2024-10-26  3:24     ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 03/13] dt-bindings: net: add bindings for NETC blocks control Wei Fang
2024-10-25 14:08   ` Rob Herring (Arm)
2024-10-24  6:53 ` [PATCH v5 net-next 04/13] net: enetc: add initial netc-blk-ctrl driver support Wei Fang
2024-10-24 16:27   ` Vladimir Oltean
2024-10-25  1:44     ` Wei Fang
2024-10-25 12:43       ` Vladimir Oltean
2024-10-26  2:47         ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 05/13] net: enetc: extract common ENETC PF parts for LS1028A and i.MX95 platforms Wei Fang
2024-10-24 16:38   ` Vladimir Oltean
2024-10-25  2:24     ` Wei Fang
2024-10-26  1:34   ` kernel test robot
2024-10-24  6:53 ` [PATCH v5 net-next 06/13] net: enetc: build enetc_pf_common.c as a separate module Wei Fang
2024-10-24 17:34   ` Vladimir Oltean
2024-10-25  3:00     ` Wei Fang
2024-10-25 13:23       ` Vladimir Oltean
2024-10-26  3:23         ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 07/13] net: enetc: remove ERR050089 workaround for i.MX95 Wei Fang
2024-10-24 17:51   ` Vladimir Oltean
2024-10-25  3:04     ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 08/13] PCI: Add NXP NETC vendor ID and device IDs Wei Fang
2024-10-24 18:16   ` Bjorn Helgaas
2024-10-25  3:13     ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 09/13] net: enetc: add i.MX95 EMDIO support Wei Fang
2024-10-24 18:00   ` Vladimir Oltean
2024-10-25  3:12     ` Wei Fang
2024-10-24 18:01   ` Vladimir Oltean
2024-10-24  6:53 ` [PATCH v5 net-next 10/13] net: enetc: extract enetc_int_vector_init/destroy() from enetc_alloc_msix() Wei Fang
2024-10-24 20:50   ` Vladimir Oltean [this message]
2024-10-25  3:27     ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 11/13] net: enetc: optimize the allocation of tx_bdr Wei Fang
2024-10-25  9:51   ` Vladimir Oltean
2024-10-26  2:37     ` Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 12/13] net: enetc: add preliminary support for i.MX95 ENETC PF Wei Fang
2024-10-24  6:53 ` [PATCH v5 net-next 13/13] MAINTAINERS: update ENETC driver files and maintainers 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=20241024205013.xw72mtssgvmwfmuu@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=Frank.Li@nxp.com \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=bhelgaas@google.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=claudiu.manoil@nxp.com \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    --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