On Thu, Oct 08, 2020 at 04:42:48PM +0000, Ertman, David M wrote:
-----Original Message----- From: Leon Romanovsky leon@kernel.org Sent: Thursday, October 8, 2020 1:00 AM To: Williams, Dan J dan.j.williams@intel.com Cc: Ertman, David M david.m.ertman@intel.com; Parav Pandit parav@nvidia.com; Pierre-Louis Bossart <pierre- louis.bossart@linux.intel.com>; alsa-devel@alsa-project.org; parav@mellanox.com; tiwai@suse.de; netdev@vger.kernel.org; ranjani.sridharan@linux.intel.com; fred.oh@linux.intel.com; linux- rdma@vger.kernel.org; dledford@redhat.com; broonie@kernel.org; Jason Gunthorpe jgg@nvidia.com; gregkh@linuxfoundation.org; kuba@kernel.org; Saleem, Shiraz shiraz.saleem@intel.com; davem@davemloft.net; Patil, Kiran kiran.patil@intel.com Subject: Re: [PATCH v2 1/6] Add ancillary bus support
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@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.
Can it be that I'm first one to use this bus for very large driver (>120K LOC) that has 5 different ->probe() flows?
For example, this https://lore.kernel.org/linux- rdma/20201006172317.GN1874917@unreal/ hints to me that this bus wasn't used with anything complex as it was initially intended.
And regarding registration, I said many times that init()/add() scheme is ok, the inability to call to uninit() after add() failure is not ok from my point of view.
So, to address your concern of not being able to call an uninit after a add failure I can break the unregister flow into two steps also. An uninit and a delete to mirror the registration process's init and add.
Would this make the registration and un-registration flow acceptable?
Yes, sure.
-DaveE
Thanks