> -----Original Message----- > From: Parav Pandit <parav@xxxxxxxxxx> > Sent: Thursday, October 8, 2020 4:10 AM > To: gregkh@xxxxxxxxxxxxxxxxxxx; Williams, Dan J <dan.j.williams@xxxxxxxxx> > Cc: Leon Romanovsky <leon@xxxxxxxxxx>; Ertman, David M > <david.m.ertman@xxxxxxxxx>; Pierre-Louis Bossart <pierre- > louis.bossart@xxxxxxxxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx; > parav@xxxxxxxxxxxx; tiwai@xxxxxxx; netdev@xxxxxxxxxxxxxxx; > ranjani.sridharan@xxxxxxxxxxxxxxx; fred.oh@xxxxxxxxxxxxxxx; linux- > rdma@xxxxxxxxxxxxxxx; dledford@xxxxxxxxxx; broonie@xxxxxxxxxx; Jason > Gunthorpe <jgg@xxxxxxxxxx>; kuba@xxxxxxxxxx; Saleem, Shiraz > <shiraz.saleem@xxxxxxxxx>; davem@xxxxxxxxxxxxx; Patil, Kiran > <kiran.patil@xxxxxxxxx> > Subject: RE: [PATCH v2 1/6] Add ancillary bus support > > > > From: gregkh@xxxxxxxxxxxxxxxxxxx <gregkh@xxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxx> > > 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
