On Tue, Jan 05, 2021 at 01:42:56PM +0000, Mark Brown wrote:
On Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
On Mon, Jan 04, 2021 at 09:19:30PM +0000, Mark Brown wrote:
Like I keep saying the same thing applies to all non-enumerable buses - exactly the same considerations exist for all the other buses like I2C (including the ACPI naming issue you mention below), and for that matter with enumerable buses which can have firmware info.
And most busses do already have their own bus type. ACPI, I2C, PCI, etc. It is just a few that have been squished into platform, notably OF.
You're missing the point there. I2C is enumerated by firmware in exactly the same way as the platform bus is, it's not discoverable from the hardware (and similarly for a bunch of other buses). If we were to say that we need separate device types for platform devices enumerated using firmware then by analogy we should do the same for devices on these other buses that happen to be enumerated by firmware.
No, I understand how I2C works and I think it is fine as is because the enumeration outcome is all standard. You always end up with a stable I2C device address (the name) and you always end up with the I2C programming API. So it doesn't matter how I2C gets enumerated, it is always an I2C device.
PCI does this too, pci_device gets crossed over to the DT data, but it is still a pci_device.
I see a big difference between attaching FW data to an existing subsystem's HW centric bus (and possibly guiding enumeration of a HW bus from FW data) and directly creating struct devices based on FW data unconnected to any existing subsystem.
The latter case is where the enumerating FW should stay on its own bus_type because there is no standardized subsystem bus providing an API or naming rules, so the FW type should provide those rules instead.
With an actual bus specific virtual function:
return dev->bus->gpio_count(dev);That won't work, you might have a mix of enumeration types for a given bus type in a single system so you'd need to do this per device.
I'm being very general here, probably what we want is a little more formal 'fw_type' concept, so a device is on a bus and also has a FW attachment which can provide this other data.
Jason