On 2/14/20 10:40 PM, Greg KH wrote:

On Fri, Feb 14, 2020 at 05:05:07PM +0100, Linus Walleij wrote:

quoted

On Fri, Jan 31, 2020 at 10:06 AM Greg KH [off-list ref] wrote:

quoted

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.

<snip>

Yeah, great explaination, and I understand.  DT stuff really is ok to be
on a platform bus, as that's what almost all of them are.

But, when you try to start messing around with things like this
"firewall" says it is doing, it's then obvious that this really isn't a
DT like thing, but rather you do have a bus involved with a controller
so that should be used instead.

Ok but how put in place a new bus while keeping the devices on platform
bus to avoid changing all the drivers ?

Or just filter away the DT stuff so that the kernel never even sees
those devices, which might just be simplest :)

yes but we lost the possibility to change the firewall configuration at
run time. I do expect to be able to describe in the DT firewall configuration
and to use them at run time. That could allow, for example, to handover
a HW block to the coprocessor when the main core is going to be suspended
to save power.

Benjamin

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel