On Thu, Oct 01, 2020 at 03:40:19PM +0100, Mark Brown wrote: > On Thu, Oct 01, 2020 at 03:12:52PM +0200, Greg KH wrote: > > On Thu, Oct 01, 2020 at 01:50:38PM +0100, Mark Brown wrote: > > > > 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. > > Right, so my concern is that as soon as we decide we want to pass some > resources or platform data through to one of the subdevices it needs to > move over into being a platform device and vice versa. That feels like > something that's going to add to the mess for some of the uses. There shouldn't be a need for resources or platform data to be passed that way as they are all "owned" by the parent device that creates these. I don't want to see platform devices become children of real devices (like PCI and USB and others), which is the goal here. platform devices are overloaded and abused enough as it is, let's not make it worse. thanks, greg k-h
