Re: [PATCH v2 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants

[Daniel Golle]

On Thu, Apr 02, 2026 at 09:57:59AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Apr 02, 2026 at 01:37:02AM +0100, Daniel Golle wrote:
> > Add compatible strings for MediaTek SoCs where the hardware random number
> > generator is accessed via a vendor-defined Secure Monitor Call (SMC)
> > rather than direct MMIO register access:
> > 
> >   - mediatek,mt7981-rng
> >   - mediatek,mt7987-rng
> >   - mediatek,mt7988-rng
> > 
> > These variants require no reg, clocks, or clock-names properties since
> > the RNG hardware is managed by ARM Trusted Firmware-A.
> > 
> > Relax the $nodename pattern to also allow 'rng' in addition to the
> > existing 'rng@...' pattern.
> > 
> > Add a second example showing the minimal SMC variant binding.
> > 
> > Signed-off-by: Daniel Golle <daniel@xxxxxxxxxxxxxx>
> > ---
> > v2: express compatibilities with fallback
> > 
> >  .../devicetree/bindings/rng/mtk-rng.yaml      | 28 ++++++++++++++++---
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> > index 7e8dc62e5d3a6..34648b53d14c6 100644
> > --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> > +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml
> > @@ -11,12 +11,13 @@ maintainers:
> >  
> >  properties:
> >    $nodename:
> > -    pattern: "^rng@[0-9a-f]+$"
> > +    pattern: "^rng(@[0-9a-f]+)?$"
> >  
> >    compatible:
> >      oneOf:
> >        - enum:
> >            - mediatek,mt7623-rng
> > +          - mediatek,mt7981-rng
> >        - items:
> >            - enum:
> >                - mediatek,mt7622-rng
> > @@ -25,6 +26,11 @@ properties:
> >                - mediatek,mt8365-rng
> >                - mediatek,mt8516-rng
> >            - const: mediatek,mt7623-rng
> > +      - items:
> > +          - enum:
> > +              - mediatek,mt7987-rng
> > +              - mediatek,mt7988-rng
> > +          - const: mediatek,mt7981-rng
> >  
> >    reg:
> >      maxItems: 1
> > @@ -38,9 +44,19 @@ properties:
> >  
> >  required:
> >    - compatible
> > -  - reg
> > -  - clocks
> > -  - clock-names
> > +
> > +allOf:
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          not:
> 
> As requested last time - drop
> 
> > +            contains:
> > +              const: mediatek,mt7981-rng
> > +    then:
> 
> missing constraints for mediatek,mt7981-rng. So does it have IO space
> and clocks or not?

The firmware variant which has the RNG under the control of TF-A and
requires Linux to use SMC to access it implies that Linux should not
touch the clk and cannot access the IO space (which is accessible from
secure-land only in this case).

Do you think something like the hunk below would properly express that?

@@ -38,9 +44,23 @@ properties:
 
 required:
   - compatible
-  - reg
-  - clocks
-  - clock-names
+
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: mediatek,mt7981-rng
+    then:
+      properties:
+        reg: false
+        clocks: false
+        clock-names: false
+    else:
+      required:
+        - reg
+        - clocks
+        - clock-names
 
 additionalProperties: false
 

> 
> > +      required:
> > +        - reg
> > +        - clocks
> > +        - clock-names
> >  
> >  additionalProperties: false
> >  
> > @@ -53,3 +69,7 @@ examples:
> >              clocks = <&infracfg CLK_INFRA_TRNG>;
> >              clock-names = "rng";
> >      };
> > +  - |
> > +    rng {
> > +            compatible = "mediatek,mt7981-rng";
> 
> No improvements.
> 
> Also, make the example complete since binding claims you have clocks and
> reg.

So clocks and reg have to be prohibited, not just allowed to be absent,
right?

> 
> I am not sure it should be even same file, but if you are making it same
> file, then make it correct.

It's the same hardware. In case of the MT7986 SoC MediaTek has even switched
from requiring the mediatek,mt7623-rng driver implementation to have the TRNG
controlled by TF-A in newer firmware, see driver implementation
auto-detecting this as a work-around...