From: "Nelson, Shannon" <shannon.nelson@amd.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: jgg@nvidia.com, andrew.gospodarek@broadcom.com,
aron.silverton@oracle.com, dan.j.williams@intel.com,
daniel.vetter@ffwll.ch, dave.jiang@intel.com, dsahern@kernel.org,
gospo@broadcom.com, hch@infradead.org, itayavr@nvidia.com,
jiri@nvidia.com, kuba@kernel.org, lbloch@nvidia.com,
leonro@nvidia.com, saeedm@nvidia.com, linux-cxl@vger.kernel.org,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
brett.creeley@amd.com
Subject: Re: [RFC PATCH fwctl 1/5] pds_core: specify auxiliary_device to be created
Date: Thu, 13 Feb 2025 14:44:44 -0800 [thread overview]
Message-ID: <eea7b6cf-5e69-4799-9faa-ef625e4545b2@amd.com> (raw)
In-Reply-To: <20250212115738.0000161b@huawei.com>
On 2/12/2025 3:57 AM, Jonathan Cameron wrote:
> On Tue, 11 Feb 2025 15:48:50 -0800
> Shannon Nelson <shannon.nelson@amd.com> wrote:
>
>> In preparation for adding a new auxiliary_device for the
>> PF, make the vif type an argument to pdsc_auxbus_dev_add().
>> We also now pass in the address to where we'll keep the new
>> padev pointer so that the caller can specify where to save it
>> but we can still change it under the mutex and keep the mutex
>> usage within the function.
>>
>> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
>
> One trivial comment inline.
>
>> ---
>> drivers/net/ethernet/amd/pds_core/auxbus.c | 41 ++++++++++-----------
>> drivers/net/ethernet/amd/pds_core/core.h | 7 +++-
>> drivers/net/ethernet/amd/pds_core/devlink.c | 6 ++-
>> drivers/net/ethernet/amd/pds_core/main.c | 11 ++++--
>> 4 files changed, 36 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/amd/pds_core/auxbus.c b/drivers/net/ethernet/amd/pds_core/auxbus.c
>> index 2babea110991..0a3035adda52 100644
>> --- a/drivers/net/ethernet/amd/pds_core/auxbus.c
>> +++ b/drivers/net/ethernet/amd/pds_core/auxbus.c
>> @@ -175,34 +175,37 @@ static struct pds_auxiliary_dev *pdsc_auxbus_dev_register(struct pdsc *cf,
>> return padev;
>> }
>>
>> -int pdsc_auxbus_dev_del(struct pdsc *cf, struct pdsc *pf)
>> +int pdsc_auxbus_dev_del(struct pdsc *cf, struct pdsc *pf,
>> + struct pds_auxiliary_dev **pd_ptr)
>> {
>> struct pds_auxiliary_dev *padev;
>> - int err = 0;
>>
>> if (!cf)
>> return -ENODEV;
>>
>> + if (!*pd_ptr)
>> + return 0;
>> +
>> mutex_lock(&pf->config_lock);
>>
>> - padev = pf->vfs[cf->vf_id].padev;
>> - if (padev) {
>> - pds_client_unregister(pf, padev->client_id);
>> - auxiliary_device_delete(&padev->aux_dev);
>> - auxiliary_device_uninit(&padev->aux_dev);
>> - padev->client_id = 0;
>> - }
>> - pf->vfs[cf->vf_id].padev = NULL;
>> + padev = *pd_ptr;
>> + pds_client_unregister(pf, padev->client_id);
>> + auxiliary_device_delete(&padev->aux_dev);
>> + auxiliary_device_uninit(&padev->aux_dev);
>> + padev->client_id = 0;
>> + *pd_ptr = NULL;
>>
>> mutex_unlock(&pf->config_lock);
>> - return err;
>> +
>> + return 0;
>
> If you are always going to return 0, maybe change the signature
> to not return anything?
>
> Would require changing the ternary usage below, but perhaps
> it is worth it to remove the implication of failures being
> a possibility.
There is the one error case in pdsc_auxbus_dev_del(), but even that is
rather useless in that any call is already going to have to have a valid
pdsc struct to get here. Yes, I can look at adding a clean-up patch to
get rid of this useless return before changing the rest of the function
signature.
sln
>
>
>> }
>>
>> -int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf)
>> +int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf,
>> + enum pds_core_vif_types vt,
>> + struct pds_auxiliary_dev **pd_ptr)
>> {
>> struct pds_auxiliary_dev *padev;
>> char devname[PDS_DEVNAME_LEN];
>> - enum pds_core_vif_types vt;
>> unsigned long mask;
>> u16 vt_support;
>> int client_id;
>> @@ -211,6 +214,9 @@ int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf)
>> if (!cf)
>> return -ENODEV;
>>
>> + if (vt >= PDS_DEV_TYPE_MAX)
>> + return -EINVAL;
>> +
>> mutex_lock(&pf->config_lock);
>>
>> mask = BIT_ULL(PDSC_S_FW_DEAD) |
>> @@ -222,17 +228,10 @@ int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf)
>> goto out_unlock;
>> }
>>
>> - /* We only support vDPA so far, so it is the only one to
>> - * be verified that it is available in the Core device and
>> - * enabled in the devlink param. In the future this might
>> - * become a loop for several VIF types.
>> - */
>> -
>> /* Verify that the type is supported and enabled. It is not
>> * an error if there is no auxbus device support for this
>> * VF, it just means something else needs to happen with it.
>> */
>> - vt = PDS_DEV_TYPE_VDPA;
>> vt_support = !!le16_to_cpu(pf->dev_ident.vif_types[vt]);
>> if (!(vt_support &&
>> pf->viftype_status[vt].supported &&
>> @@ -258,7 +257,7 @@ int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf)
>> err = PTR_ERR(padev);
>> goto out_unlock;
>> }
>> - pf->vfs[cf->vf_id].padev = padev;
>> + *pd_ptr = padev;
>>
>> out_unlock:
>> mutex_unlock(&pf->config_lock);
>> diff --git a/drivers/net/ethernet/amd/pds_core/core.h b/drivers/net/ethernet/amd/pds_core/core.h
>> index 14522d6d5f86..065031dd5af6 100644
>> --- a/drivers/net/ethernet/amd/pds_core/core.h
>> +++ b/drivers/net/ethernet/amd/pds_core/core.h
>> @@ -303,8 +303,11 @@ void pdsc_health_thread(struct work_struct *work);
>> int pdsc_register_notify(struct notifier_block *nb);
>> void pdsc_unregister_notify(struct notifier_block *nb);
>> void pdsc_notify(unsigned long event, void *data);
>> -int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf);
>> -int pdsc_auxbus_dev_del(struct pdsc *cf, struct pdsc *pf);
>> +int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf,
>> + enum pds_core_vif_types vt,
>> + struct pds_auxiliary_dev **pd_ptr);
>> +int pdsc_auxbus_dev_del(struct pdsc *cf, struct pdsc *pf,
>> + struct pds_auxiliary_dev **pd_ptr);
>>
>> void pdsc_process_adminq(struct pdsc_qcq *qcq);
>> void pdsc_work_thread(struct work_struct *work);
>> diff --git a/drivers/net/ethernet/amd/pds_core/devlink.c b/drivers/net/ethernet/amd/pds_core/devlink.c
>> index 44971e71991f..c2f380f18f21 100644
>> --- a/drivers/net/ethernet/amd/pds_core/devlink.c
>> +++ b/drivers/net/ethernet/amd/pds_core/devlink.c
>> @@ -56,8 +56,10 @@ int pdsc_dl_enable_set(struct devlink *dl, u32 id,
>> for (vf_id = 0; vf_id < pdsc->num_vfs; vf_id++) {
>> struct pdsc *vf = pdsc->vfs[vf_id].vf;
>>
>> - err = ctx->val.vbool ? pdsc_auxbus_dev_add(vf, pdsc) :
>> - pdsc_auxbus_dev_del(vf, pdsc);
>> + err = ctx->val.vbool ? pdsc_auxbus_dev_add(vf, pdsc, vt_entry->vif_id,
>> + &pdsc->vfs[vf_id].padev) :
>> + pdsc_auxbus_dev_del(vf, pdsc,
>> + &pdsc->vfs[vf_id].padev);
>> }
>>
>> return err;
>> diff --git a/drivers/net/ethernet/amd/pds_core/main.c b/drivers/net/ethernet/amd/pds_core/main.c
>> index 660268ff9562..a3a68889137b 100644
>> --- a/drivers/net/ethernet/amd/pds_core/main.c
>> +++ b/drivers/net/ethernet/amd/pds_core/main.c
>> @@ -190,7 +190,8 @@ static int pdsc_init_vf(struct pdsc *vf)
>> devl_unlock(dl);
>>
>> pf->vfs[vf->vf_id].vf = vf;
>> - err = pdsc_auxbus_dev_add(vf, pf);
>> + err = pdsc_auxbus_dev_add(vf, pf, PDS_DEV_TYPE_VDPA,
>> + &pf->vfs[vf->vf_id].padev);
>> if (err) {
>> devl_lock(dl);
>> devl_unregister(dl);
>> @@ -417,7 +418,7 @@ static void pdsc_remove(struct pci_dev *pdev)
>>
>> pf = pdsc_get_pf_struct(pdsc->pdev);
>> if (!IS_ERR(pf)) {
>> - pdsc_auxbus_dev_del(pdsc, pf);
>> + pdsc_auxbus_dev_del(pdsc, pf, &pf->vfs[pdsc->vf_id].padev);
>> pf->vfs[pdsc->vf_id].vf = NULL;
>> }
>> } else {
>> @@ -482,7 +483,8 @@ static void pdsc_reset_prepare(struct pci_dev *pdev)
>>
>> pf = pdsc_get_pf_struct(pdsc->pdev);
>> if (!IS_ERR(pf))
>> - pdsc_auxbus_dev_del(pdsc, pf);
>> + pdsc_auxbus_dev_del(pdsc, pf,
>> + &pf->vfs[pdsc->vf_id].padev);
>> }
>>
>> pdsc_unmap_bars(pdsc);
>> @@ -527,7 +529,8 @@ static void pdsc_reset_done(struct pci_dev *pdev)
>>
>> pf = pdsc_get_pf_struct(pdsc->pdev);
>> if (!IS_ERR(pf))
>> - pdsc_auxbus_dev_add(pdsc, pf);
>> + pdsc_auxbus_dev_add(pdsc, pf, PDS_DEV_TYPE_VDPA,
>> + &pf->vfs[pdsc->vf_id].padev);
>> }
>> }
>>
>
next prev parent reply other threads:[~2025-02-13 22:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 23:48 [RFC PATCH fwctl 0/5] pds_fwctl: fwctl for AMD/Pensando core devices Shannon Nelson
2025-02-11 23:48 ` [RFC PATCH fwctl 1/5] pds_core: specify auxiliary_device to be created Shannon Nelson
2025-02-12 11:57 ` Jonathan Cameron
2025-02-13 22:44 ` Nelson, Shannon [this message]
2025-02-11 23:48 ` [RFC PATCH fwctl 2/5] pds_core: add new fwctl auxilary_device Shannon Nelson
2025-02-12 12:02 ` Jonathan Cameron
2025-02-13 22:48 ` Nelson, Shannon
2025-02-12 12:03 ` Jonathan Cameron
2025-02-13 22:49 ` Nelson, Shannon
2025-02-18 19:28 ` Leon Romanovsky
2025-02-18 20:00 ` Nelson, Shannon
2025-02-19 8:24 ` Leon Romanovsky
2025-02-20 23:20 ` Nelson, Shannon
2025-02-22 18:26 ` Leon Romanovsky
2025-02-11 23:48 ` [RFC PATCH fwctl 3/5] pds_fwctl: initial driver framework Shannon Nelson
2025-02-12 12:22 ` Jonathan Cameron
2025-02-13 23:06 ` Nelson, Shannon
2025-02-14 0:55 ` Jason Gunthorpe
2025-02-12 23:26 ` Dave Jiang
2025-02-13 23:31 ` Nelson, Shannon
2025-02-18 19:51 ` Leon Romanovsky
2025-02-18 22:19 ` Nelson, Shannon
2025-02-19 8:25 ` Leon Romanovsky
2025-02-20 23:27 ` Nelson, Shannon
2025-02-22 18:29 ` Leon Romanovsky
2025-02-11 23:48 ` [RFC PATCH fwctl 4/5] pds_fwctl: add rpc and query support Shannon Nelson
2025-02-12 12:47 ` Jonathan Cameron
2025-02-13 23:13 ` Nelson, Shannon
2025-02-13 1:02 ` Dave Jiang
2025-02-13 23:34 ` Nelson, Shannon
2025-02-11 23:48 ` [RFC PATCH fwctl 5/5] pds_fwctl: add Documentation entries Shannon Nelson
2025-02-12 12:51 ` Jonathan Cameron
2025-02-12 13:13 ` Jason Gunthorpe
2025-02-12 14:23 ` Leon Romanovsky
2025-02-13 23:18 ` Nelson, Shannon
2025-02-12 13:40 ` [RFC PATCH fwctl 0/5] pds_fwctl: fwctl for AMD/Pensando core devices Andrew Lunn
2025-02-12 14:43 ` Jason Gunthorpe
2025-02-12 16:19 ` Andrew Lunn
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=eea7b6cf-5e69-4799-9faa-ef625e4545b2@amd.com \
--to=shannon.nelson@amd.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=aron.silverton@oracle.com \
--cc=brett.creeley@amd.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dave.jiang@intel.com \
--cc=dsahern@kernel.org \
--cc=gospo@broadcom.com \
--cc=hch@infradead.org \
--cc=itayavr@nvidia.com \
--cc=jgg@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=lbloch@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.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