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

[Mark Brown]

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:

> > 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.

I do too, which is why I am pushing back.

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

I know Greg has said he doesn't want this, I would like to if not change
his mind at least understand why so we can understand what we are
supposed to be doing here and ideally capture it in the documentation.

> 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.

If it is actually the case that we're not supposed to instantiate
platform devices as children of devices on actual physical buses then
there's a huge chunk of existing MFDs that are use cases, including some
PCI ones (though the PCI ones aren't great for the most part).  If it is
just PCI and USB devices then it becomes difficult to articulate the
underlying logic about why those bus types in particular.  I would
expect at least some devices instantiated on PCI attached FPGAs to also
need resources (it looks like at least one of the PCI MFDs that's been
in the tree for a long time, timberdale, is actually such a device
although not very dynamic like they could be).

I think the fundamental problem here is that this is all representing
hardware which doesn't fit neatly into abstractions and that trying to
separate out things based on abstract criteria (especially poorly
defined abstract criteria) is going to leave us with a pile of sharp
edges for people to run into, at least in terms of confusion and hassle.
The messiness that exists is I fear a reflection of reality.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20201001/3d71fdee/attachment-0001.sig>