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

[Jason Gunthorpe]

On Thu, Oct 01, 2020 at 09:17:18PM +0100, Mark Brown wrote:
> > 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.

Instead of making ancillary bus giant, it might be interesting to use
a library technique to avoid the code duplication you are talking
about, eg

 struct my_ancillary_data {
      struct ancillary_device adev;
      struct ancillary_resource resources;
 }

Then each user can access the facets they need.

Not sure what else is in platform_device or mfd_cell that is
relevant:
 - There is no DMA, these devices are not for DMA. The physical device
   pointer should be used with the DMA API.
 - resources as above
 - id/override/archdata not relavent

>From mfd_cell
 - enable/disable suspend/resume, these look like they duplicate the
   driver core stuff?
 - pdata/of_compatible/acpi_match - not applicable
 - properties - use struct members and container of
 - resources as above
 - regulators - another struct member? Only two users.

Jason