On Sat, Jan 30, 2021 at 01:19:36AM +0000, Saleem, Shiraz wrote: > > Subject: Re: [PATCH 07/22] RDMA/irdma: Register an auxiliary driver and > > implement private channel OPs > > > > On Wed, Jan 27, 2021 at 07:16:41PM -0400, Jason Gunthorpe wrote: > > > On Wed, Jan 27, 2021 at 10:17:56PM +0000, Saleem, Shiraz wrote: > > > > > > > Even with another core PCI driver, there still needs to be private > > > > communication channel between the aux rdma driver and this PCI > > > > driver to pass things like QoS updates. > > > > > > Data pushed from the core driver to its aux drivers should either be > > > done through new callbacks in a struct device_driver or by having a > > > notifier chain scheme from the core driver. > > > > Right, and internal to driver/core device_lock will protect from parallel > > probe/remove and PCI flows. > > > > OK. We will hold the device_lock while issuing the .ops callbacks from core > driver. > This should solve our synchronization issue. > > There have been a few discussions in this thread. And I would like to be > clear on what > to do. > > So we will, > > 1. Remove .open/.close, .peer_register/.peer_unregister > 2. Protect ops callbacks issued from core driver to the aux driver with > device_lock > 3. Move the custom iidc_peer_op callbacks to an irdma driver struct that > encapsulates the auxiliary driver struct. For core driver to use. > 4. Remove ice FSM around open, close etc... > 5. RDMA aux driver probe will allocate ib_device and register it at the end > of probe. > > Does this sound acceptable?
I think that it will be good start, it just hard to say in advance without seeing the end result. Thanks
