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

[Mark Brown]

On Thu, Oct 01, 2020 at 07:54:26PM +0000, Ertman, David M wrote:

> > This means that every device has to reinvent the wheel for common
> > resources like interrupts, including things like looking them up by name
> > and so on.  That doesn't seem ideal.

> It's a shared header file between the device and driver implementer.  If they
> want to share a "struct irq_data *irq" as an element in  the shared data, that is
> fine, but not everyone will need to include that.  This is why we left what is shared
> up to the implementer, so that we don't impose a debt on some other
> implementation that doesn't need it.

Realistically I think you're saying this because this has taken so long
already and you're being asked for more changes rather than because it's
a good design decision.  That is entirely understandable and reasonable
but I'm not sure it's the best decision when we have so many common
patterns between devices, one of the things that the current situtation
handles well is allowing lots of common stuff to just be data
definitions rather than code - there used to be a lot more open coding
of resource sharing.

One thing we should agree here is that we don't actually have to
implement everything right now, we just need to understand what the
design and direction of travel are.  That means that at this point it's
probably just a fairly quick documentation update rather than
substantial code changes.

> I suppose it is not the end of the world adding elements to the definition of
> struct ancillary_device, but what would be a "universal" element to add?
> Where do you draw the line on what you allow into the bus internals?  The
> overriding goal was to make a subsystem agnostic bus that doesn't impose
> implementation specific details from any single subsystem.

I think that this needs to grow everything that platform and MFD have so
that we can avoid using platform devices to represent things that are
not in the very strictest sense platform devices (which I interpret to
be memory mapped devices that can't be enumerated in some fashion).  My
understanding here is that the goal is an abstraction cleanup, it's
possible I've misunderstood though.
-------------- 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/e1dc681d/attachment-0001.sig>