lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 13 Mar 2019 10:28:41 -0300 From: Jason Gunthorpe <jgg@...pe.ca> To: Jeff Kirsher <jeffrey.t.kirsher@...el.com> Cc: "Ertman, David M" <david.m.ertman@...el.com>, "Saleem, Shiraz" <shiraz.saleem@...el.com>, "dledford@...hat.com" <dledford@...hat.com>, "davem@...emloft.net" <davem@...emloft.net>, "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Ismail, Mustafa" <mustafa.ismail@...el.com>, "Patil, Kiran" <kiran.patil@...el.com> Subject: Re: [RFC v1 01/19] net/i40e: Add peer register/unregister to struct i40e_netdev_priv On Tue, Mar 12, 2019 at 07:11:08PM -0700, Jeff Kirsher wrote: > > > I am assuming that the term PCI driver is being used to mean the PCI > > > subsystem in the kernel. If this assumption is wrong, please disregard > > > the next > > > paragraph, but the following points will still apply. > > > > No, I mean the driver that has the struct pci_driver for the PCI > > function. Maybe that is the LAN driver for this case. > > Sorry for the delayed response, I was dealing with a death in the family. My condolences > I want to make sure we are on the same page, so please correct me if I am > wrong. The Intel RDMA driver is not a stand-alone PCI function driver > because there is no separate PCI function for RDMA, so the RDMA driver does > not call pci_register_driver(), that is done with the LAN driver. The > Intel RDMA driver still needs to access to HW resources which is accessible > only through the LAN PF driver (e.g. i40e/ice) and does not have its own > netdev, so it uses the netdev exposed by the LAN PF driver. The access to > the netdev is needed so that it can listen to RT netlink messages and other > reasons. Whichever driver own the pci_driver is the one that has to setup the other driver core elements. Sounds like it is the net driver in your design. > We refer to "software bus" because out hardware doe not expose the hardware > bus, so our APIs to bus_register/unregister are actually using a software > bus, which is exposed and managed by the LAN driver. You have a multi-function device, and we have the mfd subsystem to help these cases. Probably this driver should use it. > > Register a device driver to the driver core and wait for the driver > > core to call that driver's probe method. > > Yes, the LAN PF driver is the software component exposing and managing the > bus, so it is the one who will call probe/remove of the peer driver (RDMA > driver). Although netdev notifiers based approach is needed if the RDMA > driver was loaded first before the LAN PF driver (i40e or ice) is loaded. Why would notifiers be needed? Driver core handles all these ordering things. If you have a device_driver with no device it waits until a device gets plugged in to call probe. Jason
Powered by blists - more mailing lists