[PATCH 04/10] dt-bindings: treewide: add feature-domains description in binding files

[Rob Herring]

On Fri, Jul 7, 2023 at 10:10 AM Oleksii Moisieiev
<Oleksii_Moisieiev at epam.com> wrote:
>
>
> Hi Rob,
>
> Rob Herring <robh at kernel.org> writes:
>
> > On Fri, Jul 07, 2023 at 02:07:18PM +0000, Oleksii Moisieiev wrote:
> >>
> >> Gatien Chevallier <gatien.chevallier at foss.st.com> writes:
> >>
> >> > feature-domains is an optional property that allows a peripheral to
> >> > refer to one or more feature domain controller(s).
> >> >
> >> > Description of this property is added to all peripheral binding files of
> >> > the peripheral under the STM32 firewall controllers. It allows an accurate
> >> > representation of the hardware, where various peripherals are connected
> >> > to this firewall bus. The firewall can then check the peripheral accesses
> >> > before allowing it to probe.
> >> >
> >> > Signed-off-by: Gatien Chevallier <gatien.chevallier at foss.st.com>
> >> > ---
> >> >
> >> > Disclaimer: Some error with dtbs_check will be observed as I've
> >> > considered the property to be generic, as Rob asked
> >> >
> >> >  Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml  | 4 ++++
> >> >  Documentation/devicetree/bindings/dma/st,stm32-dma.yaml      | 4 ++++
> >> >  Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml   | 4 ++++
> >> >  Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml      | 4 ++++
> >> >  Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml  | 4 ++++
> >> >  .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml      | 4 ++++
> >> >  Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml  | 4 ++++
> >> >  .../devicetree/bindings/media/cec/st,stm32-cec.yaml          | 4 ++++
> >> >  Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml   | 4 ++++
> >> >  .../bindings/memory-controllers/st,stm32-fmc2-ebi.yaml       | 4 ++++
> >> >  Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml  | 4 ++++
> >> >  Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml   | 5 +++++
> >> >  Documentation/devicetree/bindings/mmc/arm,pl18x.yaml         | 4 ++++
> >> >  Documentation/devicetree/bindings/net/stm32-dwmac.yaml       | 4 ++++
> >> >  Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml | 4 ++++
> >> >  .../devicetree/bindings/regulator/st,stm32-vrefbuf.yaml      | 4 ++++
> >> >  Documentation/devicetree/bindings/rng/st,stm32-rng.yaml      | 4 ++++
> >> >  Documentation/devicetree/bindings/serial/st,stm32-uart.yaml  | 4 ++++
> >> >  Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml    | 4 ++++
> >> >  Documentation/devicetree/bindings/sound/st,stm32-sai.yaml    | 4 ++++
> >> >  .../devicetree/bindings/sound/st,stm32-spdifrx.yaml          | 4 ++++
> >> >  Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml     | 4 ++++
> >> >  Documentation/devicetree/bindings/spi/st,stm32-spi.yaml      | 4 ++++
> >> >  Documentation/devicetree/bindings/usb/dwc2.yaml              | 4 ++++
> >> >  24 files changed, 97 insertions(+)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
> >> > index b767ec72a999..daf8dcaef627 100644
> >> > --- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
> >> > +++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
> >> > @@ -50,6 +50,10 @@ properties:
> >> >    power-domains:
> >> >      maxItems: 1
> >> >
> >> > +  feature-domains:
> >> > +    minItems: 1
> >> > +    maxItems: 3
> >> > +
> >>
> >> I beliewe feature-domains is generic binding. This means that maxItems
> >> can be implementation dependend. I would rather drop maxItems so the
> >> following format will be possible:
> >>
> >>           feature-domains = <&etzpc 1>, <&etzpc 2>, <&some_other_domain 1 2 3 4>
> >>           feature-domain-names = "firewall 1", "firewall 2", "other_domain"
> >
> > The above already allows this (not -names, but the number of entries).
> >>
> >> Also I beliewe driver will handle feature-domain-names property so it
> >> will parse feature-domains only related to the firewall.
> >
> > Now I'm curious. What's an example that's not a firewall?
> >
> > (Note I'm still not happy with the naming of 'feature' as anything is a
> > feature, but that's the least of the issues really.)
> >
>
> The alternative usages of feature-domains was originally proposed by me
> here:
> https://lore.kernel.org/lkml/c869d2751125181a55bc8a88c96e3a892b42f37a.1668070216.git.oleksii_moisieiev@epam.com/
>
> Also I remember Peng Fan also was interested in those bindings.

It helps to Cc people when you talk about them.

If the parties interested in this want to see progress on this, you
all must work together and show this is a solution for multiple
platforms.

> I think the use-case when one node is protected by firewall and also is
> controlled by scmi feature-domain-controller (As was proposed in my
> patch series) may take place.

But isn't the SCMI device protection interface the same thing? Some
interface to say "can I access this device?" and/or control access to
it.

The other possible use I'm aware of is system partitioning. OpenAMP or
similar where an SoC is partitioned into multiple OS instances and
peripherals are assigned to different partitions.

> As for the naming maybe you have some thoughts about better name?

If I did, I would have. Something with 'access' in it is as far as I've gotten.

Rob