[PATCH v3 1/2] dt-bindings: rng: bcm2835: document reset support

Nicolas Saenz Julienne nsaenzjulienne at suse.de
Thu Mar 4 12:07:36 GMT 2021


Hi Alvaro,

On Tue, 2021-02-23 at 18:00 +0100, Álvaro Fernández Rojas wrote:
> Some devices may need to perform a reset before using the RNG, such as the
> BCM6368.
> 
> Signed-off-by: Álvaro Fernández Rojas <noltari at gmail.com>
> ---
>  v3: make resets required if brcm,bcm6368-rng.
>  v2: document reset support.
> 
>  .../devicetree/bindings/rng/brcm,bcm2835.yaml   | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml
> index c147900f9041..11c23e1f6988 100644
> --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml
> +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml
> @@ -37,6 +37,21 @@ required:
>  
> 
>  additionalProperties: false

I can't claim I fully understand all the meta stuff in shemas, so I generally
just follow the patterns already available out there. That said, shoudln't this
be at the end, just before the examples? Maybe the cause of that odd warning
you got there?

> +if:
> +  properties:
> +    compatible:
> +      enum:
> +        - brcm,bcm6368-rng
> +then:
> +  properties:
> +    resets:
> +      maxItems: 1
> +  required:
> +    - resets

I belive you can't really make a property required when the bindings for
'brcm,bcm6368-rng' were already defined. This will break the schema for those
otherwise correct devicetrees.

> +else:
> +  properties:
> +    resets: false
> +
>  examples:
>    - |
>      rng at 7e104000 {
> @@ -58,4 +73,6 @@ examples:
>  
> 
>          clocks = <&periph_clk 18>;
>          clock-names = "ipsec";
> +
> +        resets = <&periph_rst 4>;
>      };

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210304/0acfaad8/attachment.sig>


More information about the linux-arm-kernel mailing list