linux-kernel - Re: [RFC PATCH 06/11] dt-bindings: soc: microchip: document the two simple-mfd syscons on PolarFire SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240815-anteater-water-d35f729c381b@spud>
Date: Thu, 15 Aug 2024 16:37:29 +0100
From: Conor Dooley <conor@...nel.org>
To: "Rob Herring (Arm)" <robh@...nel.org>
Cc: Conor Dooley <conor.dooley@...rochip.com>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, Lee Jones <lee@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>
Subject: Re: [RFC PATCH 06/11] dt-bindings: soc: microchip: document the two
 simple-mfd syscons on PolarFire SoC

On Thu, Aug 15, 2024 at 09:34:11AM -0600, Rob Herring (Arm) wrote:
> 
> On Thu, 15 Aug 2024 15:01:09 +0100, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@...rochip.com>
> > 
> > There are two syscons on PolarFire SoC that provide various functionality of
> > use to the OS.
> > 
> > The first of these is the "control-scb" region, that contains the "tvs"
> > temperature and voltage sensors and the control/status registers for the
> > system controller's mailbox. The mailbox has a dedicated node, so
> > there's no need for a child node describing it, looking the syscon up by
> > compatible is sufficient.
> > 
> > The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
> > interrupt controller and more. For this RFC, only the reset controller
> > child is described as that's all that is described by the existing
> > bindings. The clock controller already has a dedicated node, and will
> > retain it as there are other clock regions, so like the mailbox,
> > a compatible-based lookup of the syscon is sufficient to keep the clock
> > driver working as before so no child is needed.
> > 
> > Signed-off-by: Conor Dooley <conor.dooley@...rochip.com>
> > ---
> > (I'll split this in two later, it's just easier when I have the same
> > questions about both...)
> > 
> > Are these things entitled to have child nodes for the reset and sensor
> > nodes, or should the properties be in the parent and the OS probe the
> > drivers for the functions? That's something that, despite supposedly
> > being a maintainer, I do not understand the rules (of thumb?) for.
> > 
> > Secondly, is it okay to make the "pragmatic" decision to not have a
> > child clock node and keep routing the clocks via the existing & retained
> > clock node (and therefore not update the various clocks nodes in the
> > consumers)? Doing so would require a lot more hocus pocus with the clock
> > driver than this series does, as the same driver would no longer be
> > suitable for the before/after bindings.
> > ---
> >  .../microchip/microchip,mpfs-control-scb.yaml | 54 +++++++++++++++++++
> >  .../microchip,mpfs-mss-top-sysreg.yaml        | 53 ++++++++++++++++++
> >  2 files changed, 107 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
> >  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:21.13-38: Warning (reg_format): /example-0/soc/syscon@...20000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:19.27-26.13: Warning (avoid_default_addr_size): /example-0/soc/syscon@...20000: Relying on default #address-cells value
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:19.27-26.13: Warning (avoid_default_addr_size): /example-0/soc/syscon@...20000: Relying on default #size-cells value
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size'

Yeah, these are all known. One of the bindings doesn't even have an
example. I know this is automated, but just to point out that my only
objective here is figuring out whether or not child nodes are okay here.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)