From: Greg KH <gregkh@linuxfoundation.org> To: Benjamin GAIGNARD <benjamin.gaignard@st.com> Cc: "broonie@kernel.org" <broonie@kernel.org>, "robh@kernel.org" <robh@kernel.org>, "arnd@arndb.de" <arnd@arndb.de>, "shawnguo@kernel.org" <shawnguo@kernel.org>, "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>, "fabio.estevam@nxp.com" <fabio.estevam@nxp.com>, "sudeep.holla@arm.com" <sudeep.holla@arm.com>, "lkml@metux.net" <lkml@metux.net>, Loic PALLARDY <loic.pallardy@st.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-imx@nxp.com" <linux-imx@nxp.com>, "kernel@pengutronix.de" <kernel@pengutronix.de>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "system-dt@lists.openampproject.org" <system-dt@lists.openampproject.org>, "stefano.stabellini@xilinx.com" <stefano.stabellini@xilinx.com> Subject: Re: [PATCH v2 2/7] bus: Introduce firewall controller framework Date: Tue, 28 Jan 2020 17:57:12 +0100 [thread overview] Message-ID: <20200128165712.GA3667596@kroah.com> (raw) In-Reply-To: <0dd9dc95-1329-0ad4-d03d-99899ea4f574@st.com> On Tue, Jan 28, 2020 at 04:41:29PM +0000, Benjamin GAIGNARD wrote: > > On 1/28/20 4:52 PM, Greg KH wrote: > > On Tue, Jan 28, 2020 at 04:38:01PM +0100, Benjamin Gaignard wrote: > >> 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 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? > 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? > > 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. > 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? thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org> To: Benjamin GAIGNARD <benjamin.gaignard@st.com> Cc: "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>, "broonie@kernel.org" <broonie@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 Date: Tue, 28 Jan 2020 17:57:12 +0100 [thread overview] Message-ID: <20200128165712.GA3667596@kroah.com> (raw) In-Reply-To: <0dd9dc95-1329-0ad4-d03d-99899ea4f574@st.com> On Tue, Jan 28, 2020 at 04:41:29PM +0000, Benjamin GAIGNARD wrote: > > On 1/28/20 4:52 PM, Greg KH wrote: > > On Tue, Jan 28, 2020 at 04:38:01PM +0100, Benjamin Gaignard wrote: > >> 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 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? > 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? > > 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. > 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? thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-01-28 16:57 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-28 15:37 [PATCH v2 0/7] Introduce bus firewall controller framework Benjamin Gaignard 2020-01-28 15:37 ` Benjamin Gaignard 2020-01-28 15:38 ` [PATCH v2 1/7] dt-bindings: bus: Add firewall bindings Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 15:38 ` [PATCH v2 2/7] bus: Introduce firewall controller framework Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 15:52 ` Greg KH 2020-01-28 15:52 ` Greg KH 2020-01-28 16:41 ` Benjamin GAIGNARD 2020-01-28 16:41 ` Benjamin GAIGNARD 2020-01-28 16:57 ` Greg KH [this message] 2020-01-28 16:57 ` Greg KH 2020-01-28 20:29 ` Benjamin GAIGNARD 2020-01-28 20:29 ` Benjamin GAIGNARD 2020-01-29 5:49 ` Greg KH 2020-01-29 5:49 ` Greg KH 2020-01-29 9:42 ` Linus Walleij 2020-01-29 9:42 ` Linus Walleij 2020-01-29 9:52 ` Greg KH 2020-01-29 9:52 ` Greg KH 2020-01-29 11:17 ` Mark Brown 2020-01-29 11:17 ` Mark Brown 2020-01-31 8:37 ` Benjamin GAIGNARD 2020-01-31 8:37 ` Benjamin GAIGNARD 2020-01-31 9:06 ` Greg KH 2020-01-31 9:06 ` Greg KH 2020-02-14 16:05 ` Linus Walleij 2020-02-14 16:05 ` Linus Walleij 2020-02-14 21:40 ` Greg KH 2020-02-14 21:40 ` Greg KH 2020-02-15 12:41 ` Benjamin GAIGNARD 2020-02-15 12:41 ` Benjamin GAIGNARD 2020-02-16 7:21 ` Greg KH 2020-02-16 7:21 ` Greg KH 2020-01-28 15:38 ` [PATCH v2 3/7] base: Add calls to firewall controller Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 15:38 ` [PATCH v2 4/7] dt-bindings: bus: Add STM32 ETZPC " Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 15:38 ` [PATCH v2 5/7] bus: firewall: Add driver for STM32 ETZPC controller Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 15:38 ` [PATCH v2 6/7] ARM: dts: stm32: Add firewall node for stm32mp157 SoC Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 15:38 ` [PATCH v2 7/7] ARM: dts: stm32: enable firewall controller node on stm32mp157c-ed1 Benjamin Gaignard 2020-01-28 15:38 ` Benjamin Gaignard 2020-01-28 16:36 ` [PATCH v2 0/7] Introduce bus firewall controller framework Sudeep Holla 2020-01-28 16:36 ` Sudeep Holla 2020-01-28 16:46 ` Benjamin GAIGNARD 2020-01-28 16:46 ` Benjamin GAIGNARD 2020-01-28 17:17 ` Sudeep Holla 2020-01-28 17:17 ` Sudeep Holla 2020-01-28 20:06 ` Benjamin GAIGNARD 2020-01-28 20:06 ` Benjamin GAIGNARD 2020-01-28 22:06 ` Robin Murphy 2020-01-28 22:06 ` Robin Murphy 2020-01-29 13:40 ` Benjamin GAIGNARD 2020-01-29 13:40 ` Benjamin GAIGNARD 2020-01-31 18:25 ` Robin Murphy 2020-01-31 18:25 ` Robin Murphy 2020-02-03 13:16 ` Benjamin GAIGNARD 2020-02-03 13:16 ` Benjamin GAIGNARD 2020-01-31 20:51 ` Florian Fainelli 2020-01-31 20:51 ` Florian Fainelli 2020-02-03 13:41 ` Benjamin GAIGNARD 2020-02-03 13:41 ` Benjamin GAIGNARD 2020-01-31 20:48 ` Florian Fainelli 2020-01-31 20:48 ` Florian Fainelli 2020-02-02 12:23 ` Mark Brown 2020-02-02 12:23 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200128165712.GA3667596@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=arnd@arndb.de \ --cc=benjamin.gaignard@st.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=fabio.estevam@nxp.com \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lkml@metux.net \ --cc=loic.pallardy@st.com \ --cc=robh@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ --cc=stefano.stabellini@xilinx.com \ --cc=sudeep.holla@arm.com \ --cc=system-dt@lists.openampproject.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.