On Wed, Jan 29, 2020 at 10:42:39AM +0100, Linus Walleij wrote:

On Tue, Jan 28, 2020 at 9:30 PM Benjamin GAIGNARD
[off-list ref] wrote:

quoted

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

quoted

quoted

quoted

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

quoted

quoted

quoted

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

quoted

quoted

Great, then use that instead :)

quoted

I think that Linus W. will complain if I do that :)

So the similarity would be something like the way that pin control
states are configured in the device tree and the pin control
handles are taken before probe in drivers/base/pinctrl.c embedding
a hook into dd.c.

Not that it in any way controls any hardware even remotely
similar to pin control. Pin control is an electronic thing,
this firewalling is about bus access.

IIUC this framework wants to discover at kernel boot time
whether certain devices are accessible to it or not by inspecting
the state of the firewalling hardware and then avoid probing
those that are inaccessible.

It needs the same deep hooks into dd.c to achieve this
I believe.

It just needs to be part of the bus logic for the specific bus that this
"firewall" is on.  Just like we do the same thing for USB or thunderbolt
devices.  Put this in the bus-specific code please.

thanks,

greg k-h

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