On Sat, Feb 15, 2020 at 12:41:07PM +0000, Benjamin GAIGNARD wrote: > > On 2/14/20 10:40 PM, Greg KH wrote: > > On Fri, Feb 14, 2020 at 05:05:07PM +0100, Linus Walleij wrote: > >> On Fri, Jan 31, 2020 at 10:06 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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. > > <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 ? You don't, you put them all on your real bus, as that is what you now have. > > 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. Then use a real bus :) thanks, greg k-h
