Thread (34 messages) 34 messages, 7 authors, 2020-02-16

Re: [PATCH v2 2/7] bus: Introduce firewall controller framework

From: Greg KH <gregkh@linuxfoundation.org>
Date: 2020-01-29 05:49:15
Also in: linux-devicetree, lkml

On Tue, Jan 28, 2020 at 08:29:45PM +0000, Benjamin GAIGNARD wrote:
On 1/28/20 5:57 PM, Greg KH wrote:
quoted
On Tue, Jan 28, 2020 at 04:41:29PM +0000, Benjamin GAIGNARD wrote:
quoted
On 1/28/20 4:52 PM, Greg KH wrote:
quoted
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.
Great, then use that instead :)
I think that Linus W. will complain if I do that :)
quoted
quoted
I could argue that firewalls are not bus themselves they only interact
with it.
They live on a bus, and do so in bus-specific ways, right?
quoted
Bus firewalls exist on other SoC, I hope some others could be added in
this framework. ETZPC is only the first.
Then put it on the bus it lives on, and the bus that the drivers for
that device are being controlled with.  That sounds like the sane place
to do so, right?
If that means that all drivers have to be modified it will be 
problematic because not all

are specifics to the SoC.
That's fine, we have loads of drivers that work on different types of
busses.

Or, if this really is the "platform bus" then use that.  (which is what
I was hinting at all along but no one seems to realize that, should have
been more obvious...)
quoted
quoted
quoted
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
Almost 2 years ago?  I can't remember something written 1 week ago...

Yes, don't abuse the notifier chain.  I hate that thing as it is.
quoted
I have also tried to disable the nodes at runtime and Mark Rutland
explain me why it was wrong.
The bus controller should do this, right?  Why not just do it there?
The bus controller is a different hardware block.
Of course it is, but it controls a bus, and there are devices on that
bus, right?  Don't circumvent things please.

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help