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

[Ertman, David M]

> -----Original Message-----
> From: Mark Brown <broonie at kernel.org>
> Sent: Friday, October 2, 2020 4:20 AM
> To: Jason Gunthorpe <jgg at nvidia.com>
> Cc: Ertman, David M <david.m.ertman at intel.com>; 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>; parav at nvidia.com
> Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client
> support
> 
> On Thu, Oct 01, 2020 at 09:47:40PM -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 01, 2020 at 09:17:18PM +0100, Mark Brown wrote:
> 
> > 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.
> 
> The way most of this stuff works already it's not a table in the device
> itself, it's an array of resources with type information.  Your second
> struct there is presumably just going to be the pointer and size
> information which you *could* split out but I'm really not sure what
> you're buying there.
> 
> The interesting bit isn't really the data in the devices themselves,
> it's the code that allows devices to just supply a data table and have
> things mapped through to their child devices.  That isn't particularly
> complex either, but it's still worth avoiding having lots of copies of
> it.  *None* of this bus stuff is hugely complex but we still don't want
> each device with children having to open code it all when they could
> just do something data driven.

Would you recommend adding two elements to the ancillary_device like:
	void *ancillary_data;
	u32 ancildata_size;
like the platform_device uses?

-DaveE