[PATCH v2 1/6] Add ancillary bus support

[Ertman, David M]

> -----Original Message-----
> From: Parav Pandit <parav at nvidia.com>
> Sent: Thursday, October 8, 2020 4:10 AM
> To: gregkh at linuxfoundation.org; Williams, Dan J <dan.j.williams at intel.com>
> Cc: Leon Romanovsky <leon at kernel.org>; Ertman, David M
> <david.m.ertman at intel.com>; Pierre-Louis Bossart <pierre-
> louis.bossart at linux.intel.com>; alsa-devel at alsa-project.org;
> parav at mellanox.com; tiwai at suse.de; netdev at vger.kernel.org;
> ranjani.sridharan at linux.intel.com; fred.oh at linux.intel.com; linux-
> rdma at vger.kernel.org; dledford at redhat.com; broonie at kernel.org; Jason
> Gunthorpe <jgg at nvidia.com>; kuba at kernel.org; Saleem, Shiraz
> <shiraz.saleem at intel.com>; davem at davemloft.net; Patil, Kiran
> <kiran.patil at intel.com>
> Subject: RE: [PATCH v2 1/6] Add ancillary bus support
> 
> 
> > From: gregkh at linuxfoundation.org <gregkh at linuxfoundation.org>
> > Sent: Thursday, October 8, 2020 1:21 PM
> >
> > On Thu, Oct 08, 2020 at 12:38:00AM -0700, Dan Williams wrote:
> > > On Thu, Oct 8, 2020 at 12:01 AM Leon Romanovsky <leon at kernel.org>
> > wrote:
> > > [..]
> > > > All stated above is my opinion, it can be different from yours.
> > >
> > > Yes, but we need to converge to move this forward. Jason was involved
> > > in the current organization for registration, Greg was angling for
> > > this to be core functionality. I have use cases outside of RDMA and
> > > netdev. Parav was ok with the current organization. The SOF folks
> > > already have a proposed incorporation of it. The argument I am hearing
> > > is that "this registration api seems hard for driver writers" when we
> > > have several driver writers who have already taken a look and can make
> > > it work. If you want to follow on with a simpler wrappers for your use
> > > case, great, but I do not yet see anyone concurring with your opinion
> > > that the current organization is irretrievably broken or too obscure
> > > to use.
> >
> > That's kind of because I tuned out of this thread a long time ago :)
> >
> > I do agree with Leon that I think the current patch is not the correct way to
> > do this the easiest, but don't have a competing proposal to show what I
> > mean.
> >
> > Yet.
> Please consider the approach of ib_alloc_device(), ib_dealloc_device() and
> ib_register_register()/unregister().
> (a) It avoids driver calling put_device() on error unwinding path.
> (b) still achieves container_of().
> 
> >
> > Let's see what happens after 5.10-rc1 is out, it's too late now for any of this
> > for this next merge window so we can not worry about it for a few weeks.
> >
> Ok. INHO giving direction to Dave and others to either refine current APIs or
> follow ib_alloc_device() approach will be a helpful input.
> 
> ancillary bus can do better APIs than the newly (march 2020 !) introduced
> vdpa bus [1] and its drivers which follows put_device() pattern in [2] and [3]
> in error unwinding path.
> 
> [1] https://elixir.bootlin.com/linux/v5.9-rc8/source/drivers/vdpa/vdpa.c
> [2] https://elixir.bootlin.com/linux/v5.9-
> rc8/source/drivers/vdpa/ifcvf/ifcvf_main.c#L475
> [3] https://elixir.bootlin.com/linux/v5.9-
> rc8/source/drivers/vdpa/mlx5/net/mlx5_vnet.c#L1967
> 
> > thanks,
> >
> > greg k-h

IMHO we need to stay with the two step registration process that we currently
have (initialize then add) so that the driver writer knows if they need to explicitly 
free the memory allocated for auxillary_device.  Sound folks have indicated that 
this really helps their flow also.  Greg asked to have these two functions fully
commented with kernel-doc headers, which has been done.

Without enforcing an "auxillary_object" that contains just an auxillary_device and a
void pointer, we cannot do the allocation of memory in the bus infrastructure without
breaking the container_of functionality.

-DaveE