netdev - Re: [PATCH v6 net-next 01/14] pds_core: initial framework for pds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e4411a3-a25c-4369-3528-5757b42108e1@amd.com>
Date:   Sat, 25 Mar 2023 21:07:22 -0700
From:   Shannon Nelson <shannon.nelson@....com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     brett.creeley@....com, davem@...emloft.net, netdev@...r.kernel.org,
        drivers@...sando.io, leon@...nel.org, jiri@...nulli.us
Subject: Re: [PATCH v6 net-next 01/14] pds_core: initial framework for
 pds_core PF driver

On 3/25/23 4:39 PM, Jakub Kicinski wrote:
> On Fri, 24 Mar 2023 12:02:30 -0700 Shannon Nelson wrote:
>> This is the initial PCI driver framework for the new pds_core device
>> driver and its family of devices.  This does the very basics of
>> registering for the new PF PCI device 1dd8:100c, setting up debugfs
>> entries, and registering with devlink.
> 
>> +     debugfs_create_file("state", 0400, pdsc->dentry,
>> +                         pdsc, &core_state_fops);
> 
> debugfs_create_ulong() ?

Sure, that seems reasonable.  I'll double check that I don't have others 
that need the same treatment.


> 
>> diff --git a/drivers/net/ethernet/amd/pds_core/devlink.c b/drivers/net/ethernet/amd/pds_core/devlink.c
>> new file mode 100644
>> index 000000000000..a9021bfe680a
>> --- /dev/null
>> +++ b/drivers/net/ethernet/amd/pds_core/devlink.c
>> @@ -0,0 +1,51 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright(c) 2023 Advanced Micro Devices, Inc */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/types.h>
>> +#include <linux/errno.h>
>> +#include <linux/pci.h>
>> +
>> +#include "core.h"
>> +
>> +static const struct devlink_ops pdsc_dl_ops = {
>> +};
>> +
>> +static const struct devlink_ops pdsc_dl_vf_ops = {
>> +};
>> +
>> +struct pdsc *pdsc_dl_alloc(struct device *dev, bool is_pf)
>> +{
>> +     const struct devlink_ops *ops;
>> +     struct devlink *dl;
>> +
>> +     ops = is_pf ? &pdsc_dl_ops : &pdsc_dl_vf_ops;
>> +     dl = devlink_alloc(ops, sizeof(struct pdsc), dev);
>> +     if (!dl)
>> +             return NULL;
>> +
>> +     return devlink_priv(dl);
>> +}
>> +
>> +void pdsc_dl_free(struct pdsc *pdsc)
>> +{
>> +     struct devlink *dl = priv_to_devlink(pdsc);
>> +
>> +     devlink_free(dl);
>> +}
>> +
>> +int pdsc_dl_register(struct pdsc *pdsc)
>> +{
>> +     struct devlink *dl = priv_to_devlink(pdsc);
>> +
>> +     devlink_register(dl);
>> +
>> +     return 0;
>> +}
>> +
>> +void pdsc_dl_unregister(struct pdsc *pdsc)
>> +{
>> +     struct devlink *dl = priv_to_devlink(pdsc);
>> +
>> +     devlink_unregister(dl);
> 
> Don't put core devlink functionality in a separate file.
> You're not wrapping all pci_* calls in your own wrappers, why are you
> wrapping delvink? And use explicit locking, please. devl_* APIs.

Wrapping the devlink_register gives me the ability to abstract out the 
bit of additional logic that gets added in a later patch, and now the 
locking logic you mention, and is much like how other relatively current 
drivers have done it, such as in ionic, ice, and mlx5.

Sure, I can set up the dev_lock() and use the newer devl_* APIs.

sln