netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Shannon Nelson <shannon.nelson@amd.com>
Cc: brett.creeley@amd.com, davem@davemloft.net,
	netdev@vger.kernel.org, kuba@kernel.org, drivers@pensando.io,
	jiri@resnulli.us
Subject: Re: [PATCH RFC v4 net-next 11/13] pds_core: add the aux client API
Date: Wed, 15 Mar 2023 10:21:22 +0200	[thread overview]
Message-ID: <20230315082122.GM36557@unreal> (raw)
In-Reply-To: <398bef7a-795b-d105-d8e5-57ef1c39049c@amd.com>

On Tue, Mar 14, 2023 at 09:53:25AM -0700, Shannon Nelson wrote:
> On 3/14/23 5:14 AM, Leon Romanovsky wrote:
> > On Tue, Mar 07, 2023 at 09:13:08PM -0800, Shannon Nelson wrote:
> > > Add the client API operations for registering, unregistering,
> > > and running adminq commands.  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@amd.com>
> > > ---
> > >   drivers/net/ethernet/amd/pds_core/auxbus.c | 134 ++++++++++++++++++++-
> > >   include/linux/pds/pds_auxbus.h             |  42 +++++++
> > >   2 files changed, 174 insertions(+), 2 deletions(-)
> > 
> > <...>
> > 
> > > +static struct pds_core_ops pds_core_ops = {
> > > +     .register_client = pds_client_register,
> > > +     .unregister_client = pds_client_unregister,
> > > +     .adminq_cmd = pds_client_adminq_cmd,
> > > +};
> > 
> > <...>
> > 
> > > +/*
> > > + *   ptrs to functions to be used by the client for core services
> > > + */
> > > +struct pds_core_ops {
> > > +     /* .register() - register the client with the device
> > > +      * padev:  ptr to the client device info
> > > +      * Register the client with the core and with the DSC.  The core
> > > +      * will fill in the client padrv->client_id for use in calls
> > > +      * to the DSC AdminQ
> > > +      */
> > > +     int (*register_client)(struct pds_auxiliary_dev *padev);
> > > +
> > > +     /* .unregister() - disconnect the client from the device
> > > +      * padev:  ptr to the client device info
> > > +      * Disconnect the client from the core and with the DSC.
> > > +      */
> > > +     int (*unregister_client)(struct pds_auxiliary_dev *padev);
> > > +
> > > +     /* .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);
> > > +};
> > 
> > I don't expect to see any register/unregister AUX client code at all.
> > 
> > All clients are registered and unregistered through
> > auxiliary_driver_register()/auxiliary_driver_unregister() calls and
> > perform as standalone drivers.
> > 
> > Maybe client, register and unregister words means something else in this
> > series..
> 
> Yeah, I'm not thrilled with the overlap in nomenclature either.  In this
> case we're talking about the logic in the pds_vdpa module connecting to the
> services needed in the device FW, and getting a client_id from the FW that
> is used for tracking client context in the FW.  Maybe these names can change
> to something like "fw_client_reg" and "fw_client_unreg" - would that make it
> more clear?

I feel that such ops are not needed at all. Once you create aux devices
(vdpa, eth, e.t.c), you would be able to connect only one driver with one
such device. It means context is already known at that point. In addition,
user controls if he/she wants aux specific devices by relevant devlink *_enable
knob.

Thanks

> 
> sln
> 
> 
> > 
> > Thanks
> > 
> > >   #endif /* _PDSC_AUXBUS_H_ */
> > > --
> > > 2.17.1
> > > 

  reply	other threads:[~2023-03-15  8:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08  5:12 [PATCH RFC v4 net-next 00/13] pds_core driver Shannon Nelson
2023-03-08  5:12 ` [PATCH RFC v4 net-next 01/13] pds_core: initial framework for pds_core PF driver Shannon Nelson
2023-03-08  5:12 ` [PATCH RFC v4 net-next 02/13] pds_core: add devcmd device interfaces Shannon Nelson
2023-03-08  9:37   ` Jiri Pirko
2023-03-09  2:05     ` Shannon Nelson
2023-03-09  9:29       ` Jiri Pirko
2023-03-09 22:25         ` Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 03/13] pds_core: health timer and workqueue Shannon Nelson
2023-03-08  9:39   ` Jiri Pirko
2023-03-09  2:08     ` Shannon Nelson
2023-03-09  9:30       ` Jiri Pirko
2023-03-09 22:26         ` Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 04/13] pds_core: set up device and adminq Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 05/13] pds_core: Add adminq processing and commands Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 06/13] pds_core: add FW update feature to devlink Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 07/13] pds_core: set up the VIF definitions and defaults Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 08/13] pds_core: add initial VF device handling Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 09/13] pds_core: add auxiliary_bus devices Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 10/13] pds_core: devlink params for enabling VIF support Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 11/13] pds_core: add the aux client API Shannon Nelson
2023-03-14 12:14   ` Leon Romanovsky
2023-03-14 16:53     ` Shannon Nelson
2023-03-15  8:21       ` Leon Romanovsky [this message]
2023-03-16  1:08         ` Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 12/13] pds_core: publish events to the clients Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 13/13] pds_core: Kconfig and pds_core.rst Shannon Nelson

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=20230315082122.GM36557@unreal \
    --to=leon@kernel.org \
    --cc=brett.creeley@amd.com \
    --cc=davem@davemloft.net \
    --cc=drivers@pensando.io \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shannon.nelson@amd.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;
as well as URLs for NNTP newsgroup(s).