On Wed, Sep 30, 2020 at 03:50:46PM -0700, Dave Ertman wrote:
> Documentation/driver-api/ancillary_bus.rst | 230 +++++++++++++++++++++
> Documentation/driver-api/index.rst | 1 +
It would probably be useful to have the documentation in a separate
patch, it's a huge proportion of the patch and would make it much more
approachable.
> +are controlled by DT/ACPI. The same argument applies for not using MFD in this
> +scenario as MFD relies on individual function devices being physical devices
> +that are DT enumerated.
See my commments on the cover letter about MFD, this is just not true.
> +An example for this kind of requirement is the audio subsystem where a single
> +IP is handling multiple entities such as HDMI, Soundwire, local devices such as
> +mics/speakers etc. The split for the core's functionality can be arbitrary or
This is not a requirement of the audio subsystem, this is to do with how
the Intel audio hardware has been implemented on their modern SoCs.
> +int ancillary_device_initialize(struct ancillary_device *ancildev)
> +{
> +int __ancillary_device_add(struct ancillary_device *ancildev, const char *modname)
> +{
It can be useful to have this split but there's also going to be plenty
of cases where people just need to register a device based on the struct
ancilliary_device straight away so it would be good to at least have a
standard ancilliary_device_new() (or whatever) that does both steps in
one. As Greg said in his review this split model is a bit more fiddly
to use and frequently leads to error handling problems in drivers.
Attachment:
signature.asc
Description: PGP signature
