[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdY427EzpAt7f5wwqHpRS_SHM8Fvm+cFrwY8op0E_J+D9Q@mail.gmail.com>
Date: Wed, 29 Jan 2020 10:42:39 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Benjamin GAIGNARD <benjamin.gaignard@...com>
Cc: Greg KH <gregkh@...uxfoundation.org>,
"robh@...nel.org" <robh@...nel.org>,
Loic PALLARDY <loic.pallardy@...com>,
"arnd@...db.de" <arnd@...db.de>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"system-dt@...ts.openampproject.org"
<system-dt@...ts.openampproject.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"broonie@...nel.org" <broonie@...nel.org>,
"lkml@...ux.net" <lkml@...ux.net>,
"linux-imx@....com" <linux-imx@....com>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"sudeep.holla@....com" <sudeep.holla@....com>,
"fabio.estevam@....com" <fabio.estevam@....com>,
"stefano.stabellini@...inx.com" <stefano.stabellini@...inx.com>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 2/7] bus: Introduce firewall controller framework
On Tue, Jan 28, 2020 at 9:30 PM Benjamin GAIGNARD
<benjamin.gaignard@...com> wrote:
> On 1/28/20 5:57 PM, Greg KH wrote:
> > On Tue, Jan 28, 2020 at 04:41:29PM +0000, Benjamin GAIGNARD wrote:
> >> On 1/28/20 4:52 PM, Greg KH wrote:
> >>> 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 :)
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.
Yours,
Linus Walleij
Powered by blists - more mailing lists