[PATCH 0/6] Ancillary bus implementation and SOF multi-client support

[Greg KH]

On Thu, Oct 01, 2020 at 03:04:48PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 01, 2020 at 05:51:37PM +0100, Mark Brown wrote:
> > On Thu, Oct 01, 2020 at 11:20:39AM -0500, Pierre-Louis Bossart wrote:
> > 
> > > I have nothing against MFD, but if this boils down to platform devices we
> > > are back to the initial open "are platform devices suitable as children of
> > > PCI devices"? I've heard Greg say no for the last year and a half - and he
> > > just re-stated this earlier in this thread.
> > 
> > As you'll have seen from this thread and the prior version (which was
> > the first time I became aware of this stuff) I'm not clear how that
> > desire maps on to hardware, as soon as subdevices start needing to get
> > regions and interrupts mapped then we're going to end up reinventing
> > resources and regmaps AFAICT.
> 
> I think the truth is MFD and anciallary bus are solving almost the
> same problem and could meet in the middle at some point.

Agreed.

> Since Greg has completely NAK'd using pci_device inside MFD it looks
> like this is the preference.

I have NAK'd using platform devices as children for things that are not
platform devices.  MFD is the thing that is wed to platform devices at
the moment, so unless you want to change MFD to not enforce that (and
last I looked the MFD maintainer said no), then yes, we can't use MFD.

> If people have a use case for regmaps/IRQs then they should add them
> here. Right now the places I know of don't need this.
> 
> The target for this is queue-based devices where the sharing granule
> is a queue. The actual thing being shared to the subsystem from the
> PCI driver basically the ability to create a queue.

And PCI resources, you will have drivers that want that.  But those are
easy to share :)

thanks,

greg k-h