On 9/20/26 1:18 PM, Krzysztof Kozlowski wrote:
On Fri, Sep 18, 2026 at 11:52:30AM -0500, Alex Elder wrote:
Define the binding for a system controller used in the Toshiba
TC9564 SoC.
Co-developed-by: Daniel Thompson <[email protected]>
Signed-off-by: Daniel Thompson <[email protected]>
Signed-off-by: Alex Elder <[email protected]>
Thank you for your feedback, Krzysztof.
---
.../bindings/mfd/toshiba,tc9564.yaml | 56 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml
diff --git a/Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml
b/Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml
new file mode 100644
index 0000000000000..32e73a727c82a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/toshiba,tc9564.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/toshiba,tc9564.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC9564 System Controller
+
+maintainers:
+ - Alex Elder <[email protected]>
+ - Daniel Thompson <[email protected]>
+
+description: |
Do not need '|' unless you need to preserve formatting.
OK.
+ The Toshiba TC9564 is an SoC accessed by a host system through the
+ upstream PCIe port on the PCIe switch it implements. The switch includes
+ an embedded PCIe endpoint on one of its downstream ports that provides
+ access to various SoC peripherals (including a clock and reset controller)
+ via one of its BARs. A system controller provides managed access to the
+ first two pages of this memory region to ensure accesses made by these
+ peripherals produce well-defined results.
+
+properties:
+ compatible:
+ items:
+ - const: toshiba,tc9564-config
+ - const: syscon
+ - const: simple-mfd
+
+ reg:
+ maxItems: 1
+
+ ranges: true
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
Both properties and simple-mfd are redundant. You do not have children.
I think ranges, #address-cells, and #size-cells might have
been left here by mistake, and I hadn't noticed. (They are
required to be included within a pci-ep-bus sub-node, but
even if that's why they're here, they're in the wrong place.)
I will remove these three properties, as well as the
"simple-mfd" compatible string in version 2.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
And this should be additionalProperties instead
OK.
+examples:
+ - |
+ syscon@0 {
+ compatible = "toshiba,tc9564-config",
+ "syscon",
+ "simple-mfd";
+ reg = <0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
As you can see here - no children.
I have seen some examples of syscon nodes that incorporate
sub-devices, while others do not.
Our purpose for defining a syscon here is to coordinate
access for multiple devices to several registers located
within the same page of memory.
I think this device was originally defined in a sub-node
because the only memory accesses it requires are within
the range covered by the syscon.
Should we instead define the syscon to be a fairly trivial
standalone thing, and then refer to it in the clock/reset
device node by phandle? (Or have the driver look it up
by compatible string?)
tc9564_config_syscon0: syscon@0 {
compatible = "toshiba,tc9564-config",
"syscon";
reg = <0x0 0x2000>;
};
clock@1004 {
compatible = "toshiba,tc9564-clock";
toshiba,config-syscon = <&tc9564_config_syscon0 0x1004>;
#clock-cells = <1>;
#reset-cells = <1>;
};
I also have doubts that this is needed - I see no updates to the misc
binding, which would be referencing it. But then another point would be,
that you do not need separate child node, which has no properties.
I'm sorry if I'm missing something. I saw other examples of
syscon nodes being defined, and tried to copy what I saw, but
obviously got it wrong.
Well, has one - address space.
Lack of full picture is not helping here.
I will gladly provide a better picture, but I also want to
stay focused on what's necessary for the binding.
I have more in my next message.
-Alex
Best regards,
Krzysztof
