Mon, Nov 11, 2019 at 04:46:01AM CET, jakub.kicinski@xxxxxxxxxxxxx wrote: >On Sun, 10 Nov 2019 10:18:55 +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote: >> > What I'm missing is why is it so bad to have a driver register to >> > multiple subsystems. >> >> Because these PCI devices seem to do "different" things all in one PCI >> resource set. Blame the hardware designers :) > >See below, I don't think you can blame the HW designers in this >particular case :) > >> > For the nfp I think the _real_ reason to have a bus was that it >> > was expected to have some out-of-tree modules bind to it. Something >> > I would not encourage :) >> >> That's not ok, and I agree with you. >> >> But there seems to be some more complex PCI devices that do lots of >> different things all at once. Kind of like a PCI device that wants to >> be both a keyboard and a storage device at the same time (i.e. a button >> on a disk drive...) > >The keyboard which is also a storage device may be a clear cut case >where multiple devices were integrated into one bus endpoint. Also, I think that very important differentiator between keyboard/button and NIC is that keyboard/button is fixed. You have driver bus with 2 devices on constant addresses. However in case of NIC subfunctions. You have 0 at he beginning and user instructs to create more (maybe hundreds). Now important questions appear: 1) How to create devices (what API) - mdev has this figured out 2) How to to do the addressing of the devices. Needs to be predictable/defined by the user - mdev has this figured out 3) Udev names of netdevices - udev names that according to the bus/address. That is straightforeward with mdev. I can't really see how to figure this one in particular with per-driver busses :/ > >The case with these advanced networking adapters is a little different >in that they are one HW device which has oodles of FW implementing >clients or acceleration for various networking protocols. > >The nice thing about having a fake bus is you can load out-of-tree >drivers to operate extra protocols quite cleanly. > >I'm not saying that's what the code in question is doing, I'm saying >I'd personally like to understand the motivation more clearly before >every networking driver out there starts spawning buses. The only >argument I've heard so far for the separate devices is reloading subset >of the drivers, which I'd rate as moderately convincing.
