Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 16 Feb 2020 08:21:11 +0100
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Benjamin GAIGNARD <benjamin.gaignard@st.com>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Grant Likely <grant.likely@arm.com>,
        "robh@kernel.org" <robh@kernel.org>,
        Loic PALLARDY <loic.pallardy@st.com>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "system-dt@lists.openampproject.org" 
        <system-dt@lists.openampproject.org>,
        "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "lkml@metux.net" <lkml@metux.net>,
        "linux-imx@nxp.com" <linux-imx@nxp.com>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
        "fabio.estevam@nxp.com" <fabio.estevam@nxp.com>,
        "stefano.stabellini@xilinx.com" <stefano.stabellini@xilinx.com>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/7] bus: Introduce firewall controller framework
Message-ID: <20200216072111.GA14598@kroah.com>
References: <20200128165712.GA3667596@kroah.com>
 <62b38576-0e1a-e30e-a954-a8b6a7d8d897@st.com>
 <CACRpkdY427EzpAt7f5wwqHpRS_SHM8Fvm+cFrwY8op0E_J+D9Q@mail.gmail.com>
 <20200129095240.GA3852081@kroah.com>
 <20200129111717.GA3928@sirena.org.uk>
 <0b109c05-24cf-a1c4-6072-9af8a61f45b2@st.com>
 <20200131090650.GA2267325@kroah.com>
 <CACRpkdajhivkOkZ63v-hr7+6ObhTffYOx5uZP0P-MYvuVnyweA@mail.gmail.com>
 <20200214214051.GA4192967@kroah.com>
 <409eb745-aab2-86a7-bd3a-9e8e05bed057@st.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <409eb745-aab2-86a7-bd3a-9e8e05bed057@st.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Feb 15, 2020 at 12:41:07PM +0000, Benjamin GAIGNARD wrote:
> 
> 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 <gregkh@linuxfoundation.org> 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 ?

You don't, you put them all on your real bus, as that is what you now
have.

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

Then use a real bus :)

thanks,

greg k-h