linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: Mark Brown <broonie@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	loic pallardy <loic.pallardy@st.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>
Subject: Re: [RFC 0/7] Introduce bus domains controller framework
Date: Thu, 17 Jan 2019 11:57:21 -0600	[thread overview]
Message-ID: <CAL_JsqKwj46CSB8vRbYyU6kRMTXqa2Q6O=vQkJwTwC_gHjOf-g@mail.gmail.com> (raw)
In-Reply-To: <20190114144202.27315-1-benjamin.gaignard@st.com>

On Mon, Jan 14, 2019 at 8:42 AM Benjamin Gaignard
<benjamin.gaignard@st.com> wrote:
>
> The goal of this framework is to offer an interface for the
> hardware blocks controlling bus accesses rights.
>
> Bus domains controllers are typically used to control if a
> hardware block can perform read or write operations on bus.

Lots of things are domains. Power domains, clock domains, etc. But
naming is hard.

We now have the inter-connect binding which ATM only deals with
bandwidth. Any reason we can't add access controls to that?

> Smarter domains controllers could be able to define accesses
> rights per hardware blocks to control where they can read
> or write.
>
> Domains controller configurations are provided in device node,
> parsed by the framework and send to the driver to apply them.
> Each controller may need different number and type of inputs
> to configure a domain so device-tree properties size have to
> be define by using "#domainctrl-cells".
> Domains configurations properties have to be named "domainsctrl-X"
> on device node.
> "domainsctrl-names" keyword can also be used to give a name to
> a specific configuration.
>
> An example of bus domains controller is STM32 ETZPC hardware block
> which got 3 domains:
> - secure: hardware blocks are only accessible by software running on trust
>   zone.
> - non-secure: hardware blocks are accessible by non-secure software (i.e.
>   linux kernel).
> - coprocessor: hardware blocks are only accessible by the corpocessor.

We already have a way to assign secure vs. non-secure with 'status'.
Ignoring co-processors for a minute, why does that not work for you?

Co-processors are so varied in terms of capabilities and view of the
system, I'm not sure we can define something generic.

> Up to 94 hardware blocks of the soc could be managed by ETZPC and
> assigned to one of the three domains.
>
> It is an RFC, comments are welcome to help to create this framework, thanks.

Finally, for a new, common binding, I'd like to see more than one
platform using it (or at least an intent to use it).

Rob

  parent reply	other threads:[~2019-01-17 17:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 14:41 [RFC 0/7] Introduce bus domains controller framework Benjamin Gaignard
2019-01-14 14:41 ` [RFC 1/7] devicetree: bindings: Document domains controller bindings Benjamin Gaignard
2019-01-16 17:30   ` Mark Brown
2019-01-17 13:20     ` Benjamin GAIGNARD
2019-01-17 16:22       ` Mark Brown
2019-01-14 14:41 ` [RFC 2/7] domainsctrl: Introduce domains controller framework Benjamin Gaignard
2019-01-17 17:27   ` Mark Brown
2019-01-18  9:26     ` Benjamin GAIGNARD
2019-01-21 12:56       ` Mark Brown
2019-01-14 14:41 ` [RFC 3/7] base: Add calls to domains controller Benjamin Gaignard
2019-01-14 14:41 ` [RFC 4/7] devicetree: bindings: domainsctrl: Add STM32 ETZPC bindings Benjamin Gaignard
2019-01-14 14:42 ` [RFC 5/7] bus: domainsctrl: Add driver for STM32 ETZPC controller Benjamin Gaignard
2019-01-14 14:42 ` [RFC 6/7] ARM: dts: stm32: Add domainsctrl node for stm32mp157 SoC Benjamin Gaignard
2019-01-14 14:42 ` [RFC 7/7] ARM: dts: stm32: enable domains controller node on stm32mp157c-ed1 Benjamin Gaignard
2019-01-17 17:57 ` Rob Herring [this message]
2019-01-18  9:56   ` [RFC 0/7] Introduce bus domains controller framework Benjamin GAIGNARD

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='CAL_JsqKwj46CSB8vRbYyU6kRMTXqa2Q6O=vQkJwTwC_gHjOf-g@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=arnd@arndb.de \
    --cc=benjamin.gaignard@linaro.org \
    --cc=benjamin.gaignard@st.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).