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@xxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxx> > > --- > > (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@37020000: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@37020000: 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@37020000: 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.
Attachment:
signature.asc
Description: PGP signature