On Fri, Jan 31, 2020 at 10:06 AM Greg KH gregkh@linuxfoundation.org wrote:
Why do people want to abuse the platform bus so much? If a device is on a bus that can have such a controller, then it is on a real bus, use it!
I'm not saying it is a good thing, but the reason why it is (ab)used so much can be found in: drivers/of/platform.c
TL;DR: struct platform_device is the Device McDeviceFace and platform bus the Bus McBusFace used by the device tree parser since it is slightly to completely unaware of what devices it is actually spawning.
And everything and its dog is using device tree in the embedded world. (A quick glance in drivers/acpi gives me the impression that ACPI is doing the very same thing but I am not a domain expert there so I am not really sure.)
Whenever a device is created from a device tree it gets spawned on either the platform bus or the amba bus. In 99 cases out of 100 it is going to be a platform_device.
In most device trees all devices ultimately spawn from the device tree and the root of absolutely everything including irq chips on the SoC, timers, PCI hosts and USB root hubs and whatnot is a platform device, because that is how the core device tree parser has chosen to spawn off devices.
This generic code goes back to commit eca3930163ba8884060ce9d9ff5ef0d9b7c7b00f "of: Merge of_platform_bus_type with platform_bus_type" where the device tree-specific bus was replaced by the platform bus. This code was then moved down to drivers/of and used in multiple architectures. Grant's patch makes perfect sense because at the time some devices were created using board files (thus platform_device) and others using device tree and having two different probe paths and driver files for this reason alone was not reasonable. The same reasoning will apply to ACPI vs device tree drivers.
What we *could* have done was to handle special devices special, like happened for AMBA PrimeCells. Mea Culpa, I suppose I am one of the guilty.
Supporting new bus types for root devices in systems described in device tree would requiring patching drivers/of/platform.c and people are afraid of that because the code there is pretty complex.
Instead platform_device is (ab)used to carry stuff over from the device tree to respective subsystem.
In some cases the struct platform_device from device tree is discarded after use, it is just left dangling in memory with no other purpose than to serve as .parent for whatever device on whatever bus we were really creating.
For some devices such as root irq_chips they serve no purpose whatsoever, they are just created and sitting around never to be probed, because the code instantiating them parse the device tree directly.
For the devices that actually probe to drive a piece of silicon, arguably a different type of device on a different bus should be created, such as (I am making this up) struct soc_device on soc_bus. (Incidentally soc_bus exists, but its current use case is not for this.)
I don't really see any better option for Benjamin or anyone else though?
The reason why it is used so much should at least be clarified now I think.
Yours, Linus Walleij