Messages in this thread | | | From | Rob Herring <> | Date | Thu, 17 Jan 2019 11:57:21 -0600 | Subject | Re: [RFC 0/7] Introduce bus domains controller framework |
| |
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
| |