On Thu, Oct 01, 2020 at 01:50:38PM +0100, Mark Brown wrote: > 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. This series doesn't really show how this is ment to be used, from what I can tell. The goal is to NOT need a platform device/bus as that's an overloaded/abused subsystem, and to just use a much lighter-weight subsystem that allows one "device" (PCI/USB/whatever) to have multiple child devices that then are bound to different subsystems (networking, tty, input, etc.) Yes, there will be some core "sharing" needed, but that's up to the driver that implements this, not the generic code. > > 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. This new bus doesn't need DT at all. Or at least it better not... But again, this series doesn't really feel like it is showing what this is really for to me as there is just one "child device" that is being created, just to handle debugfs files, which aren't even part of the driver model. Again, I could have this totally wrong, if so, someone needs to point out my errors in reviewing this. thanks, greg k-h
