On Wed, Sep 30, 2020 at 03:50:45PM -0700, Dave Ertman wrote: > In some subsystems, the functionality of the core device > (PCI/ACPI/other) may be too complex for a single device to be managed as > a monolithic block or a part of the functionality might need to be > exposed to a different subsystem. Splitting the functionality into > smaller orthogonal devices makes it easier to manage data, power > management and domain-specific communication with the hardware. Also, > common ancillary_device functionality across primary devices can be > handled by a common ancillary_device. A key requirement for such a split > is that there is no dependency on a physical bus, device, register > accesses or regmap support. These individual devices split from the core > cannot live on the platform bus as they are not physical devices that I have to say that I find the motivation behind this bus to be a bit confusing. In code terms it's essentially a stripped back copy of the platform bus and we're basically assigning devices between the two based on if they end up having a physical resource passed through to them. That seems to result in some duplication, has some potential for devices to need to churn between the two buses and for duplication in parent devices if they need to create both platform and auxiliary devices. What exactly is the problem we're trying to solve here beyond the labelling one? I can see that it's a bit messy but this whole area is a bit messy and I'm not clear that we're not just pushing the mess around. > 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.
Attachment:
signature.asc
Description: PGP signature
