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

[Ertman, David M]

> -----Original Message-----
> From: Mark Brown <broonie at kernel.org>
> Sent: Thursday, October 1, 2020 12:39 PM
> To: Ertman, David M <david.m.ertman at intel.com>
> Cc: Greg KH <gregkh at linuxfoundation.org>; alsa-devel at alsa-project.org;
> tiwai at suse.de; pierre-louis.bossart at linux.intel.com; Sridharan, Ranjani
> <ranjani.sridharan at intel.com>; jgg at nvidia.com; parav at nvidia.com
> Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client
> support
> 
> On Thu, Oct 01, 2020 at 06:29:58PM +0000, Ertman, David M wrote:
> 
> > > I would like to move those PCI MFDs away from that, and into this bus
> > > instead.
> 
> > > If there needs to have a way to pass/share resources, great, let's add
> > > it, there's no objection from me.
> 
> OK, if we can add resource passing then no huge problem from my end
> since there'd be no case where you couldn't use an ancillairy device.
> It's still a bit confusing but there's no cases where we're supposed to
> use an ancilliary device but it doesn't have required features.
> 
> > The sharing of information is done by having the parent driver declare
> > the ancillary_device as an element in a parent_struct that also contains a
> > pointer to the shared information.  This way, when the ancillary_driver
> > is probed, and a pointer to ancillary_device is passed, it can perform a
> > container_of on the ancillary_device and gain access to the shared data.
> 
> > This keeps all requirements out of the ancillary bus code and it can be
> > as flexible as the implementer wants it to be.
> 
> 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.

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.

-DaveE

-DaveE