[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94a4ae9e-bd27-1553-593c-89b8bb9d0360@amd.com>
Date: Mon, 10 Apr 2023 13:50:52 -0700
From: Shannon Nelson <shannon.nelson@....com>
To: Leon Romanovsky <leon@...nel.org>
Cc: brett.creeley@....com, davem@...emloft.net, netdev@...r.kernel.org,
kuba@...nel.org, drivers@...sando.io, jiri@...nulli.us
Subject: Re: [PATCH v9 net-next 12/14] pds_core: add the aux client API
On 4/9/23 10:07 AM, Leon Romanovsky wrote:
>
> On Thu, Apr 06, 2023 at 04:41:41PM -0700, Shannon Nelson wrote:
>> Add the client API operations for running adminq commands.
>> The core registers the client with the FW, then the client
>> has a context for requesting adminq services. We expect
>> to add additional operations for other clients, including
>> requesting additional private adminqs and IRQs, but don't have
>> the need yet.
>>
>> Signed-off-by: Shannon Nelson <shannon.nelson@....com>
>> ---
>> drivers/net/ethernet/amd/pds_core/auxbus.c | 135 ++++++++++++++++++++-
>> include/linux/pds/pds_auxbus.h | 28 +++++
>> 2 files changed, 160 insertions(+), 3 deletions(-)
>
> <...>
>
>> +static struct pds_core_ops pds_core_ops = {
>> + .adminq_cmd = pds_client_adminq_cmd,
>> +};
>> +
>
> <...>
>
>> diff --git a/include/linux/pds/pds_auxbus.h b/include/linux/pds/pds_auxbus.h
>> index aa0192af4a29..f98efd578e1c 100644
>> --- a/include/linux/pds/pds_auxbus.h
>> +++ b/include/linux/pds/pds_auxbus.h
>> @@ -10,7 +10,35 @@ struct pds_auxiliary_dev {
>> struct auxiliary_device aux_dev;
>> struct pci_dev *vf_pdev;
>> struct pci_dev *pf_pdev;
>> + struct pds_core_ops *ops;
>
> I honestly don't understand why pds_core functionality is espoused
> through ops callbacks on auxdevice. IMHO, they shouldn't be callbacks
> and that functionality shouldn't operate on auxdevice.
The original design had several more operations and wrapped all the
interaction into a single defined interface rather that polluting the
kernel with additional direct EXPORTed functions from the PF. Since
much has disappeared as we simplified the interface and don't yet have
use for some of them, this ops struct with its single entry is the last
vestige of that idea.
Perhaps it is time to put it away and add one more EXPORTed function.
We can revisit this idea if/when the interface grows again.
>
> Thanks
>
>> u16 client_id;
>> void *priv;
>> };
>> +
>> +/*
>> + * ptrs to functions to be used by the client for core services
>> + */
>> +struct pds_core_ops {
>> + /* .adminq_cmd() - process an adminq request for the client
>> + * padev: ptr to the client device
>> + * req: ptr to buffer with request
>> + * req_len: length of actual struct used for request
>> + * resp: ptr to buffer where answer is to be copied
>> + * flags: optional flags defined by enum pds_core_adminq_flags
>> + * and used for more flexible adminq behvior
>> + *
>> + * returns 0 on success, or
>> + * negative for error
>> + * Client sends pointers to request and response buffers
>> + * Core copies request data into pds_core_client_request_cmd
>> + * Core sets other fields as needed
>> + * Core posts to AdminQ
>> + * Core copies completion data into response buffer
>> + */
>> + int (*adminq_cmd)(struct pds_auxiliary_dev *padev,
>> + union pds_core_adminq_cmd *req,
>> + size_t req_len,
>> + union pds_core_adminq_comp *resp,
>> + u64 flags);
>> +};
>> #endif /* _PDSC_AUXBUS_H_ */
>> --
>> 2.17.1
>>
Powered by blists - more mailing lists