[Linux-stm32] [PATCH v3 2/6] dt-bindings: treewide: add feature-domains description in binding files

[Oleksii Moisieiev]

On 03.02.23 22:57, Rob Herring wrote:

On Fri, Jan 27, 2023 at 05:40:36PM +0100, Gatien Chevallier wrote:


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 System Bus. 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><mailto:gatien.chevallier at foss.st.com>
---

Patch not present in V1 and V2.

 Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml | 5 +++++
 Documentation/devicetree/bindings/dma/st,stm32-dma.yaml     | 5 +++++
 Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml  | 5 +++++
 Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml     | 5 +++++
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml | 5 +++++
 .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml     | 5 +++++
 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml | 5 +++++
 Documentation/devicetree/bindings/media/st,stm32-cec.yaml   | 5 +++++
 Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml  | 5 +++++
 .../bindings/memory-controllers/st,stm32-fmc2-ebi.yaml      | 5 +++++
 Documentation/devicetree/bindings/mfd/st,stm32-lptimer.yaml | 5 +++++
 Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml  | 6 ++++++
 Documentation/devicetree/bindings/mmc/arm,pl18x.yaml        | 5 +++++
 Documentation/devicetree/bindings/net/stm32-dwmac.yaml      | 5 +++++
 .../devicetree/bindings/phy/phy-stm32-usbphyc.yaml          | 5 +++++
 .../devicetree/bindings/regulator/st,stm32-vrefbuf.yaml     | 5 +++++
 Documentation/devicetree/bindings/rng/st,stm32-rng.yaml     | 5 +++++
 Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 5 +++++
 Documentation/devicetree/bindings/sound/st,stm32-i2s.yaml   | 5 +++++
 Documentation/devicetree/bindings/sound/st,stm32-sai.yaml   | 5 +++++
 .../devicetree/bindings/sound/st,stm32-spdifrx.yaml         | 5 +++++
 Documentation/devicetree/bindings/spi/st,stm32-qspi.yaml    | 5 +++++
 Documentation/devicetree/bindings/spi/st,stm32-spi.yaml     | 5 +++++
 Documentation/devicetree/bindings/usb/dwc2.yaml             | 5 +++++
 24 files changed, 121 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
index 4ccb335e8063..cb2ad7d5fdb5 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
@@ -41,6 +41,11 @@ properties:
     maximum: 2
     default: 0

+  feature-domains:
+    $ref: /schemas/feature-controllers/feature-domain-controller.yaml#/properties/feature-domains



Not how common properties work. Consumer properties should be in a
schema with 'select: true' (the one you are referencing) and here you
just need to define the entries. Like clocks, power-domains, etc.



+    minItems: 1
+    maxItems: 3



Why is this variable and what is each entry?

I still don't like the naming. Everything is a feature and a domain...

It might be a bit easier to come up with a name with multiple users of
this binding presented. I'm hesistant to define any new common binding
with only 1 user as I've said multiple times on this binding.

Rob


Hi Rob,

Previously, I've introduced a patch series, which are also using those bindings:
Link: https://lkml.org/lkml/2022/11/10/183
Where I intended is to use feature domain controller producer/consumer bindings on the virtualized systems.
Here is a little quote from the cover letter, which describes how I expect to use those bindings:

""


The feature device controller conception in the virtualized systems is to
set the device configuration for SCMI (System Control and Management
Interface) which controls clocks/power-domains/resets etc from the
Firmware. This configuration sets the device_id to set the device
permissions for the Firmware using BASE_SET_DEVICE_PERMISSIONS
message (see 4.2.2.10 of [0]).
""

Binding example:
""
Feature-Domains in Device-tree node example:
usb at e6590000
{
    feature-domains = <&scmi 19>; //Set domain id 19 to usb node
    feature-domain-names = "scmi";
    ...
};

&scmi {
    feature-domain-controller;
    #feature-domain-cells = <1>;
}
"""

The name "feature-domain-controller" is the result of the discussion in the following thread:
https://patchwork.ozlabs.org/project/devicetree-bindings/cover/cover.1657187536.git.oleksii_moisieiev@epam.com

We've decided that that this name fits both our tasks. Maybe you can suggest a name that fits better for both our requirements?

Also, there was a letter from Peng Fan in the provided thread. So probably NXP also interested in those bindings and can potentially use it in their device nodes.

Best regards,
Oleksii

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://st-md-mailman.stormreply.com/pipermail/linux-stm32/attachments/20230206/7e97626a/attachment.html>