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
