[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f7b99e11-c331-4613-8112-4fb5387649e8@wanadoo.fr>
Date: Mon, 21 Apr 2025 11:51:50 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Gur Stavi <gur.stavi@...wei.com>, Fan Gong <gongfan1@...wei.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
linux-doc@...r.kernel.org, Jonathan Corbet <corbet@....net>,
Bjorn Helgaas <helgaas@...nel.org>, luosifu <luosifu@...wei.com>,
Xin Guo <guoxin09@...wei.com>, Shen Chenyang <shenchenyang1@...ilicon.com>,
Zhou Shuai <zhoushuai28@...wei.com>, Wu Like <wulike1@...wei.com>,
Shi Jing <shijing34@...wei.com>, Meny Yossefi <meny.yossefi@...wei.com>,
Lee Trager <lee@...ger.us>, Michael Ellerman <mpe@...erman.id.au>,
Suman Ghosh <sumang@...vell.com>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Joe Damato <jdamato@...tly.com>
Subject: Re: [PATCH net-next v11 1/1] hinic3: module initialization and tx/rx
logic
Le 21/04/2025 à 09:47, Gur Stavi a écrit :
> From: Fan Gong <gongfan1@...wei.com>
>
> This is [1/3] part of hinic3 Ethernet driver initial submission.
> With this patch hinic3 is a valid kernel module but non-functional
> driver.
>
> The driver parts contained in this patch:
> Module initialization.
> PCI driver registration but with empty id_table.
> Auxiliary driver registration.
> Net device_ops registration but open/stop are empty stubs.
> tx/rx logic.
>
> All major data structures of the driver are fully introduced with the
> code that uses them but without their initialization code that requires
> management interface with the hw.
>
> Co-developed-by: Xin Guo <guoxin09@...wei.com>
> Signed-off-by: Xin Guo <guoxin09@...wei.com>
> Signed-off-by: Fan Gong <gongfan1@...wei.com>
> Co-developed-by: Gur Stavi <gur.stavi@...wei.com>
> Signed-off-by: Gur Stavi <gur.stavi@...wei.com>
> ---
Hi,
a few nitpick, should it help and in case of a v12.
> +static const struct auxiliary_device_id hinic3_nic_id_table[] = {
> + {
> + .name = HINIC3_NIC_DRV_NAME ".nic",
> + },
> + {},
Unneeded trailing , after a terminator.
> +};
...
> +int hinic3_alloc_txqs(struct net_device *netdev)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_hwdev *hwdev = nic_dev->hwdev;
> + u16 q_id, num_txqs = nic_dev->max_qps;
> + struct pci_dev *pdev = nic_dev->pdev;
> + struct hinic3_txq *txq;
> + u64 txq_size;
> +
> + txq_size = num_txqs * sizeof(*nic_dev->txqs);
> + if (!txq_size) {
I think that if (!num_txqs) would be enough.
> + dev_err(hwdev->dev, "Cannot allocate zero size txqs\n");
> + return -EINVAL;
> + }
> +
> + nic_dev->txqs = kzalloc(txq_size, GFP_KERNEL);
and kcalloc() could be used here. (even if it is trivial that it can not
overflow)
> + if (!nic_dev->txqs)
> + return -ENOMEM;
> +
> + for (q_id = 0; q_id < num_txqs; q_id++) {
> + txq = &nic_dev->txqs[q_id];
> + txq->netdev = netdev;
> + txq->q_id = q_id;
> + txq->q_depth = nic_dev->q_params.sq_depth;
> + txq->q_mask = nic_dev->q_params.sq_depth - 1;
> + txq->dev = &pdev->dev;
> + }
> +
> + return 0;
> +}
...
> +netdev_tx_t hinic3_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + u16 q_id = skb_get_queue_mapping(skb);
> + struct hinic3_txq *txq;
> +
> + if (unlikely(!netif_carrier_ok(netdev))) {
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
Why not goto err_drop_pkt;?
> + }
> +
> + if (unlikely(q_id >= nic_dev->q_params.num_qps)) {
> + txq = &nic_dev->txqs[0];
Why update txd? It won't be used after the goto.
> + goto err_drop_pkt;
> + }
> + txq = &nic_dev->txqs[q_id];
> +
> + return hinic3_send_one_skb(skb, netdev, txq);
> +
> +err_drop_pkt:
> + dev_kfree_skb_any(skb);
> + return NETDEV_TX_OK;
> +}
...
CJ
Powered by blists - more mailing lists