On Fri, Sep 27, 2019 at 06:03:51PM +0000, Ertman, David M wrote: > > From: [email protected] [mailto:[email protected]] > > Sent: Thursday, September 26, 2019 10:13 PM > > To: Nguyen, Anthony L <[email protected]> > > Cc: Kirsher, Jeffrey T <[email protected]>; [email protected]; > > [email protected]; [email protected]; [email protected]; > > Ertman, David M <[email protected]> > > Subject: Re: [RFC 01/20] ice: Initialize and register multi-function device > > to > > provide RDMA > > > > On Thu, Sep 26, 2019 at 11:39:22PM +0000, Nguyen, Anthony L wrote: > > > On Thu, 2019-09-26 at 20:05 +0200, Greg KH wrote: > > > > On Thu, Sep 26, 2019 at 09:45:00AM -0700, Jeff Kirsher wrote: > > > > > From: Tony Nguyen <[email protected]> > > > > > > > > > > The RDMA block does not advertise on the PCI bus or any other bus. > > > > > > > > Huh? How do you "know" where it is then? Isn't is usually assigned > > > > to a PCI device? > > > > > > The RDMA block does not have its own PCI function so it must register > > > and interact with the ice driver. > > > > So the "ice driver" is the real thing controlling the pci device? How does > > it > > "know" about the RDMA block? > > > > thanks, > > > > greg k-h > > The ICE driver loads and registers to control the PCI device. It then > creates an MFD device with the name 'ice_rdma'. The device data provided to > the MFD subsystem by the ICE driver is the struct iidc_peer_dev which > contains all of the relevant information that the IRDMA peer will need > to access this PF's IIDC API callbacks > > The IRDMA driver loads as a software only driver, and then registers a MFD > function driver that takes ownership of MFD devices named 'ice_rdma'. > This causes the platform bus to perform a matching between ICE's MFD device > and IRDMA's driver. Then the patform bus will call the IRDMA's IIDC probe > function. This probe provides the device data to IRDMA.
Did any resolution happen here? Dave, do you know what to do to get Greg's approval? Jason
