All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin GAIGNARD <benjamin.gaignard@st.com>
To: Greg KH <gregkh@linuxfoundation.org>
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 16:41:29 +0000	[thread overview]
Message-ID: <0dd9dc95-1329-0ad4-d03d-99899ea4f574@st.com> (raw)
In-Reply-To: <20200128155243.GC3438643@kroah.com>


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.

I could argue that firewalls are not bus themselves they only interact 
with it.

Bus firewalls exist on other SoC, I hope some others could be added in 
this framework. ETZPC is only the first.

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

I have also tried to disable the nodes at runtime and Mark Rutland 
explain me why it was wrong.

Benjamin

>
> thanks,
>
> greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin GAIGNARD <benjamin.gaignard@st.com>
To: Greg KH <gregkh@linuxfoundation.org>
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 16:41:29 +0000	[thread overview]
Message-ID: <0dd9dc95-1329-0ad4-d03d-99899ea4f574@st.com> (raw)
In-Reply-To: <20200128155243.GC3438643@kroah.com>


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.

I could argue that firewalls are not bus themselves they only interact 
with it.

Bus firewalls exist on other SoC, I hope some others could be added in 
this framework. ETZPC is only the first.

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

I have also tried to disable the nodes at runtime and Mark Rutland 
explain me why it was wrong.

Benjamin

>
> thanks,
>
> greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-28 16:41 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 [this message]
2020-01-28 16:41       ` Benjamin GAIGNARD
2020-01-28 16:57       ` Greg KH
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=0dd9dc95-1329-0ad4-d03d-99899ea4f574@st.com \
    --to=benjamin.gaignard@st.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=gregkh@linuxfoundation.org \
    --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: link
Be 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.