[v2,1/8] dt-bindings: arm/npcm: Add binding for global control registers (GCR)

A nuvoton,*-gcr node is present in nuvoton-common-npcm7xx.dtsi and will
be added to nuvoton-wpcm450.dtsi. It is necessary for the NPCM7xx and
WPCM450 pinctrl drivers, and may later be used to retrieve SoC model and
version information.

This patch adds a binding to describe this node.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

---
v2:
- Rename node in example to syscon@800000
- Add subnode to example

v1:
- https://lore.kernel.org/lkml/20210602120329.2444672-2-j.neuschaefer@gmx.net/
---
 .../bindings/arm/npcm/nuvoton,gcr.yaml        | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml

--
2.30.2

On Tue, 07 Dec 2021 22:08:16 +0100, Jonathan Neuschäfer wrote:
> A nuvoton,*-gcr node is present in nuvoton-common-npcm7xx.dtsi and will
> be added to nuvoton-wpcm450.dtsi. It is necessary for the NPCM7xx and
> WPCM450 pinctrl drivers, and may later be used to retrieve SoC model and
> version information.
> 
> This patch adds a binding to describe this node.
> 
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> 
> ---
> v2:
> - Rename node in example to syscon@800000
> - Add subnode to example
> 
> v1:
> - https://lore.kernel.org/lkml/20210602120329.2444672-2-j.neuschaefer@gmx.net/
> ---
>  .../bindings/arm/npcm/nuvoton,gcr.yaml        | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.example.dt.yaml: syscon@800000: 'uart-mux-controller' does not match any of the regexes: 'pinctrl-[0-9]+'
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.example.dt.yaml: uart-mux-controller: $nodename:0: 'uart-mux-controller' does not match '^mux-controller(@.*|-[0-9a-f]+)?$'
	From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mux/mux-controller.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1564899

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

On Fri, Dec 10, 2021 at 08:54:33AM -0600, Rob Herring wrote:
> On Tue, Dec 07, 2021 at 10:08:16PM +0100, Jonathan Neuschäfer wrote:
> > A nuvoton,*-gcr node is present in nuvoton-common-npcm7xx.dtsi and will
> > be added to nuvoton-wpcm450.dtsi. It is necessary for the NPCM7xx and
> > WPCM450 pinctrl drivers, and may later be used to retrieve SoC model and
> > version information.
> > 
> > This patch adds a binding to describe this node.
> > 
> > Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> > 
> > ---
[...]
> > +description: |
> 
> Don't need '|' if no formatting.

Ok, I'll drop it.

> > +  The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs
> > +  that expose misc functionality such as chip model and version information or
> > +  pinmux settings.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +          - nuvoton,wpcm450-gcr
> > +          - nuvoton,npcm750-gcr
> > +      - const: syscon
> > +      - const: simple-mfd
> 
> blank line

I'll add it.

> > +  reg: true
> 
> Need to define how many entries:
> 
> maxItems: 1

Ok

> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false

Ah, oops, I missed that I still had this line, when I added the child
node to the example.

> Ideally, you should define the child node names, but you can do this:
> 
> additionalProperties:
>   type: object
> 
> which means anything undefined must be a node.

Ok, makes sense, thanks.


Thanks,
Jonathan