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

[Ertman, David M]

> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
> Sent: Thursday, October 1, 2020 7:07 AM
> To: Mark Brown <broonie at kernel.org>; Ertman, David M
> <david.m.ertman at intel.com>
> Cc: alsa-devel at alsa-project.org; tiwai at suse.de;
> gregkh at linuxfoundation.org; Sridharan, Ranjani
> <ranjani.sridharan at intel.com>; parav at nvidia.com; jgg at nvidia.com
> Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client
> support
> 
> 
> 
> >> are controlled by DT/ACPI. The same argument applies for not using MFD
> >> in this scenario as it relies on individual function devices being
> >> physical devices that are DT enumerated.
> >
> > MFD has no reliance on devices being DT enumerated, it works on systems
> > that don't have DT and in many cases it's not clear that the split you'd
> > want for the way Linux describes devices is a sensible one for other
> > operating systems so we don't want to put it into DT.  Forcing things to
> > be DT enumerated would just create needless ABIs.
> 
> I agree the "DT enumerated" part should be removed.
> 
> To the best of my knowledge, the part of 'individual function devices
> being physical devices' is correct though. MFDs typically expose
> different functions on a single physical bus, and the functions are
> separated out by register maps. In the case where there's no physical
> bus/device and no register map it's unclear how MFDs would help?

The MFD bus also uses parts of the platform bus in the background, including
platform_data and the such.  We submitted a version of the RDMA/LAN solution
using MFD and it was NACK'd by GregKH.

-DaveE