-----Original Message----- From: Mark Brown broonie@kernel.org Sent: Thursday, October 1, 2020 12:39 PM To: Ertman, David M david.m.ertman@intel.com Cc: Greg KH gregkh@linuxfoundation.org; alsa-devel@alsa-project.org; tiwai@suse.de; pierre-louis.bossart@linux.intel.com; Sridharan, Ranjani ranjani.sridharan@intel.com; jgg@nvidia.com; parav@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