On 1/28/20 4:52 PM, Greg KH wrote:

On Tue, Jan 28, 2020 at 04:38:01PM +0100, Benjamin Gaignard wrote:

quoted

The goal of this framework is to offer an interface for the
hardware blocks controlling bus accesses rights.

Bus firewall controllers are typically used to control if a
hardware block can perform read or write operations on bus.

So put this in the bus-specific code that controls the bus that these
devices live on.  Why put it in the driver core when this is only on one
"bus" (i.e. the catch-all-and-a-bag-of-chips platform bus)?

It is really similar to what pin controller does, configuring an 
hardware block given DT information.

I could argue that firewalls are not bus themselves they only interact 
with it.

Bus firewalls exist on other SoC, I hope some others could be added in 
this framework. ETZPC is only the first.

And really, this should just be a totally new bus type, right?  And any
devices on this bus should be changed to be on this new bus, and the
drivers changed to support them, instead of trying to overload the
platform bus with more stuff.

I have tried to use the bus notifier to avoid to add this code at probe 
time but without success:

https://lkml.org/lkml/2018/2/27/300

I have also tried to disable the nodes at runtime and Mark Rutland 
explain me why it was wrong.

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