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