[lkml]   [2020]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 2/7] bus: Introduce firewall controller framework

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 <> 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 ?

> 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.


> thanks,
> greg k-h
 \ /
  Last update: 2020-02-15 13:42    [W:0.091 / U:3.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site