> -----Original Message----- > From: gregkh@xxxxxxxxxxxxxxxxxxx [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, September 26, 2019 10:13 PM > To: Nguyen, Anthony L <anthony.l.nguyen@xxxxxxxxx> > Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@xxxxxxxxx>; jgg@xxxxxxxxxxxx; > netdev@xxxxxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx; dledford@xxxxxxxxxx; > Ertman, David M <david.m.ertman@xxxxxxxxx> > 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 <anthony.l.nguyen@xxxxxxxxx> > > > > > > > > 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. Dave E
