Hi Pierre, Mark, Dan, > From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > Sent: Wednesday, October 7, 2020 10:12 PM > > > >>> "virtual" here means "not real" :) > > > >> Which of these aux device use cases is not a real device? One of my > >> planned usages for this facility is for the NPEM (Native PCIE > >> Enclosure Management) mechanism that can appear on any PCIE > >> bridge/endpoint. While it is true that the NPEM register set does not > >> get its own PCI-b:d:f address on the host bus, it is still > >> discoverable by a standard enumeration scheme. It is real auxiliary > >> device functionality that can appear on any PCIE device where the > >> kernel can now have one common NPEM driver for all instances in the > >> topology. > > > > Some if not all of the SOF cases are entirely software defined by the > > firmware downloaded to the audio DSPs. > > Correct for DSP processing/debug stuff. In some cases though, the firmware > deals with different IOs (HDMI, I2C) and having multiple 'aux' > devices helps expose unrelated physical functions in a more modular way. > > The non-SOF audio case I can think of is SoundWire. We want to expose > SoundWire links as separate devices even though they are not exposed in > the platform firmware or PCI configs (decision driven by Windows). We > currently use platform devices for this, but we'd like to transition to this 'aux' > bus There is more updated version of the patch [1] from Dave which is covering multiple mailing list who are also going to consume this bus. This includes (a) mlx5 subdevices for netdev, rdma and more carved from a pci device. (b) mlx5 matching service to load multiple drivers on for a given PCI PF/VF/subfunction. (similar use case as irdma) Greg also mentioned that he likes to see other mailing list CCed, which Dave already did in PATCHv2 at [1]. So lets please discuss in thread [1]? [1] https://lore.kernel.org/linux-rdma/20201005182446.977325-1-david.m.ertman@xxxxxxxxx/
