From: "Rob Herring (Arm)" <robh@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Lee Jones <lee@kernel.org>, Conor Dooley <conor+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>
Subject: Re: [RFC PATCH 06/11] dt-bindings: soc: microchip: document the two simple-mfd syscons on PolarFire SoC
Date: Thu, 15 Aug 2024 09:34:11 -0600 [thread overview]
Message-ID: <172373604945.1948429.11074973738435374630.robh@kernel.org> (raw)
In-Reply-To: <20240815-pending-sacrifice-f2569ed756fe@spud>
On Thu, 15 Aug 2024 15:01:09 +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.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@microchip.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@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'
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240815-pending-sacrifice-f2569ed756fe@spud
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
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 after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
next prev parent reply other threads:[~2024-08-15 15:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 14:01 [RFC PATCH 00/11] Rules for simple-mfd child nodes Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 01/11] dt-bindings: mailbox: mpfs: fix reg properties Conor Dooley
2024-08-15 15:34 ` Rob Herring (Arm)
2024-08-15 14:01 ` [RFC PATCH 02/11] hwmon: add a driver for the temp/voltage sensor on PolarFire SoC Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 03/11] mailbox: mpfs: support fixed binding (TODO: always use regmap) Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 04/11] riscv: dts: microchip: fix mailbox description (TODO drop 3rd syscon from here) Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 05/11] dt-bindings: mfd: syscon document the non simple-mfd syscon on PolarFire SoC Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 06/11] dt-bindings: soc: microchip: document the two simple-mfd syscons " Conor Dooley
2024-08-15 15:34 ` Rob Herring (Arm) [this message]
2024-08-15 15:37 ` Conor Dooley
2024-08-15 16:27 ` Conor Dooley
2024-08-15 20:00 ` Rob Herring
2024-08-15 20:42 ` Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 07/11] reset: mpfs: add non-auxiliary bus probing Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 08/11] copy meson clk-regmap for now Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 09/11] clk: microchip: mpfs: use regmap clock types Conor Dooley
2024-08-15 14:01 ` [RFC PATCH 10/11] dt-bindings: clk: microchip: mpfs: remove first reg region Conor Dooley
2024-08-15 15:34 ` Rob Herring (Arm)
2024-08-15 14:01 ` [RFC PATCH 11/11] riscv: dts: microchip: convert clock and reset (TODO: fixup phandle) Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=172373604945.1948429.11074973738435374630.robh@kernel.org \
--to=robh@kernel.org \
--cc=conor+dt@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®