From: Aviad Krawczyk <aviad.krawczyk@huawei.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: <davem@davemloft.net>, <linux-kernel@vger.kernel.org>,
<netdev@vger.kernel.org>, <bc.y@huawei.com>,
<victor.gissin@huawei.com>, <zhaochen6@huawei.com>,
<tony.qu@huawei.com>
Subject: Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface
Date: Sun, 23 Jul 2017 13:30:53 +0300 [thread overview]
Message-ID: <33fbbf34-cdbe-81a8-dc33-2cd6cb6cf4ee@huawei.com> (raw)
In-Reply-To: <20170719222740.GA1755@electric-eye.fr.zoreil.com>
Hi Francois,
ERR_PTR / IS ERR - we will change it
err_xyz labels - we will change it according to other companies style.
hinic_free_hwdev - It is there to mark us changes for VF code. We will remove it,
it can't be failed.
hinic_remove - If insmod failed and someone calls rmmod, we will get a crash because
the resource are already free. Therefore we test if the device exists, please tell me
if you meant to something different
pci_id_tbl - will be moved to the .c file.
void* - usually void * is something to avoid.
The priv data is in type void * because the
caller can use any struct that it wants, like the priv data in Linux
(netdev, irq, tasklet, work..) -
we can change it but if we will pass different struct
in the future, we will have to change the prototype of the functions.
According to the other void *:
The wq struct is used for cmdq, sq and rq. Therefore the wqe is in type
void *. There are 4 operations get_wqe, write_wqe, read_wqe and put_wqe - there
is no option that one function will be fed with a wrong pointer because the caller
should use what it got in get_wqe function.
When something is used as multiple types, it can be used as void * or union.
Usually, I would prefer union. But, in this case if we will use union, maybe there is a chance
of using the wrong wqe type in the wrong work queue type.
Another option is to use a wrapper for each wq type operations, so only the basic wq ops will
use void *.
Then, there will be cmdq, rq, sq operations with the correct wqe type and wq operations that
will use void *.
I will be glad to hear your opinion about the preferred style and about hinic_remove issue you mentioned
above.
Thanks for your time and review,
Aviad
On 7/20/2017 1:27 AM, Francois Romieu wrote:
> Aviad Krawczyk <aviad.krawczyk@huawei.com> :
> [...]
>> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
>> new file mode 100644
>> index 0000000..fbc9de4
>> --- /dev/null
>> +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> [...]
>> +/**
>> + * hinic_init_hwdev - Initialize the NIC HW
>> + * @hwdev: the NIC HW device that is returned from the initialization
>> + * @pdev: the NIC pci device
>> + *
>> + * Return 0 - Success, negative - Failure
>> + *
>> + * Initialize the NIC HW device and return a pointer to it in the first arg
>> + **/
>
> Return a pointer and use ERR_PTR / IS_ERR ?
>
>> +int hinic_init_hwdev(struct hinic_hwdev **hwdev, struct pci_dev *pdev)
>> +{
>> + struct hinic_pfhwdev *pfhwdev;
>> + struct hinic_hwif *hwif;
>> + int err;
>> +
>> + hwif = devm_kzalloc(&pdev->dev, sizeof(*hwif), GFP_KERNEL);
>> + if (!hwif)
>> + return -ENOMEM;
>> +
>> + err = hinic_init_hwif(hwif, pdev);
>> + if (err) {
>> + dev_err(&pdev->dev, "Failed to init HW interface\n");
>> + return err;
>> + }
>> +
>> + if (!HINIC_IS_PF(hwif) && !HINIC_IS_PPF(hwif)) {
>> + dev_err(&pdev->dev, "Unsupported PCI Function type\n");
>> + err = -EFAULT;
>> + goto func_type_err;
>> + }
>> +
>> + pfhwdev = devm_kzalloc(&pdev->dev, sizeof(*pfhwdev), GFP_KERNEL);
>> + if (!pfhwdev) {
>> + err = -ENOMEM;
>> + goto pfhwdev_alloc_err;
>
> Intel, Mellanox, Broadcom, Amazon and friends use "err_xyz" labels.
>
> Please consider using the same style.
>
> [...]
>> +void hinic_free_hwdev(struct hinic_hwdev *hwdev)
>> +{
>> + struct hinic_hwif *hwif = hwdev->hwif;
>> + struct pci_dev *pdev = hwif->pdev;
>> + struct hinic_pfhwdev *pfhwdev;
>> +
>> + if (!HINIC_IS_PF(hwif) && !HINIC_IS_PPF(hwif)) {
>> + dev_err(&pdev->dev, "unsupported PCI Function type\n");
>> + return;
>> + }
>
> If it succeeded in hinic_init_hwdev, how could it fail here ?
>
> If it failed in hinic_init_hwdev, hinic_free_hwdev should not even
> be called.
>
> -> remove ?
>
> [...]
>> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_main.c b/drivers/net/ethernet/huawei/hinic/hinic_main.c
>> new file mode 100644
>> index 0000000..c61c769
>> --- /dev/null
>> +++ b/drivers/net/ethernet/huawei/hinic/hinic_main.c
> [...]
>> +static void hinic_remove(struct pci_dev *pdev)
>> +{
>> + struct net_device *netdev = pci_get_drvdata(pdev);
>> + struct hinic_dev *nic_dev;
>> +
>> + if (!netdev)
>> + return;
>
> Your driver is flawed if this test can ever succeed.
>
> [...]
>> +static int __init hinic_init(void)
>> +{
>> + return pci_register_driver(&hinic_driver);
>> +}
>> +
>> +static void __exit hinic_exit(void)
>> +{
>> + pci_unregister_driver(&hinic_driver);
>> +}
>
> Use module_pci_driver(hinic_driver).
>
> Remove hinic_init() and hinic_exit().
>
>> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_pci_id_tbl.h b/drivers/net/ethernet/huawei/hinic/hinic_pci_id_tbl.h
>> new file mode 100644
>> index 0000000..1d92617
>> --- /dev/null
>> +++ b/drivers/net/ethernet/huawei/hinic/hinic_pci_id_tbl.h
> [...]
>> +#ifndef HINIC_PCI_ID_TBL_H
>> +#define HINIC_PCI_ID_TBL_H
>> +
>> +#ifndef PCI_VENDOR_ID_HUAWEI
>> +#define PCI_VENDOR_ID_HUAWEI 0x19e5
>> +#endif
>
> Useless: it duplicates include/linux/pci_ids.h
>
>> +
>> +#ifndef PCI_DEVICE_ID_HI1822_PF
>> +#define PCI_DEVICE_ID_HI1822_PF 0x1822
>> +#endif
>
> Please move it to the .c file where it is actually used.
>
>
> Extra:
>
> grep -E 'void\ \*' drivers/net/ethernet/huawei/hinic/* makes me nervous.
>
> At some point one function will be fed with a wrong pointer and the
> compiler won't notice it.
>
> For instance hinic_sq_read_wqe is only called with &skb. There's no
> reason to declare it using a 'void **' argument.
>
next prev parent reply other threads:[~2017-07-23 10:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-19 9:18 [PATCH V2 net-next 00/21] Huawei HiNIC Ethernet Driver Aviad Krawczyk
2017-07-19 9:18 ` [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface Aviad Krawczyk
2017-07-19 22:27 ` Francois Romieu
2017-07-23 10:30 ` Aviad Krawczyk [this message]
2017-07-24 23:03 ` Francois Romieu
2017-07-25 14:50 ` Aviad Krawczyk
2017-07-25 20:02 ` Francois Romieu
2017-07-26 12:48 ` Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 02/21] net-next/hinic: Initialize hw device components Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 03/21] net-next/hinic: Initialize api cmd resources Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 04/21] net-next/hinic: Initialize api cmd hw Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 05/21] net-next/hinic: Add management messages Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 06/21] net-next/hinic: Add api cmd commands Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 07/21] net-next/hinic: Add aeqs Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 08/21] net-next/hinic: Add port management commands Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 09/21] net-next/hinic: Add Rx mode and link event handler Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 10/21] net-next/hinic: Add logical Txq and Rxq Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 11/21] net-next/hinic: Add wq Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 12/21] net-next/hinic: Add qp resources Aviad Krawczyk
2017-07-19 23:13 ` David Miller
2017-07-23 10:07 ` Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 13/21] net-next/hinic: Set qp context Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 14/21] net-next/hinic: Initialize cmdq Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 15/21] net-next/hinic: Add ceqs Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 16/21] net-next/hinic: Add cmdq commands Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 17/21] net-next/hinic: Add cmdq completion handler Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 18/21] net-next/hinic: Add Rx handler Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 19/21] net-next/hinic: Add Tx operation Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 20/21] net-next/hinic: Add ethtool and stats Aviad Krawczyk
2017-07-19 10:27 ` Joe Perches
2017-07-19 12:36 ` Aviad Krawczyk
2017-07-26 22:33 ` Andrew Lunn
2017-07-30 9:59 ` Aviad Krawczyk
2017-07-19 9:19 ` [PATCH V2 net-next 21/21] net-next/hinic: Add select_queue and netpoll Aviad Krawczyk
2017-07-19 11:34 ` Sergei Shtylyov
2017-07-19 12:41 ` Aviad Krawczyk
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=33fbbf34-cdbe-81a8-dc33-2cd6cb6cf4ee@huawei.com \
--to=aviad.krawczyk@huawei.com \
--cc=bc.y@huawei.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
--cc=tony.qu@huawei.com \
--cc=victor.gissin@huawei.com \
--cc=zhaochen6@huawei.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
Powered by JetHome