RE: [PATCH v2 2/3] dt-bindings: mfd: Add Realtek MISC system controller

On 17/11/2025 12:03, Yu-Chun Lin [林祐君] wrote:

quoted

Hi Conor and Krzysztof,

quoted

Documentation/devicetree/bindings/mfd/realtek,misc.yaml

diff --git a/Documentation/devicetree/bindings/mfd/realtek,misc.yaml

b/Documentation/devicetree/bindings/mfd/realtek,misc.yaml
new file mode 100644
index 000000000000..4f4a9ae250be

--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/realtek,misc.yaml

@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/realtek,misc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek MISC System Controller
+
+description:
+  The Realtek MISC System Controller is a register area that
+contains
+  miscellaneous system registers for the SoC and serves as a parent
+node
+  for other functions.
+
+maintainers:
+  - James Tai <james.tai@realtek.com>
+  - Yu-Chun Lin <eleanor.lin@realtek.com>
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - realtek,misc

I apologize for the current compatible string, which was initially
named by referencing existing patterns like 'brcm,misc' and thus
violates the naming guidance against "wildcards" and general non-SoC

specific names.

quoted

Let me explain the purpose of the device node (Realtek system controller).

This MISC area contains several peripheral sub-modules such as uart,
watchdog, rtc or i2c ..... These blocks share a unified register
region implemented as a single hardware module, which remains powered
during system suspend states (e.g., S3). These blocks share the same
MMIO region and appear as child nodes under the MISC syscon node.
Currently, it

No, you are mixing hardware with DT representation. This device cannot
appear as child node, because there is no such concept in hardware as child
node. You cannot use argument of DT representation when you justify how this
is represented in DT. It is invalid.

You need to start argumentation in terms of hardware.

You are right that there is no hardware parent-child relationship between the MISC
controller and the UART block. The MISC registers at 0x98007000 are a system control
(syscon) module, while the UART controller is a separate IP mapped at 0x98007800
on the same RBUS.
In v3, I will moved the UART node to be a direct child of the RBUS bus node.

quoted

includes uart.

Regarding the current structure, the device node is defined in a
kent.dtsi and is included by each SoC's DTSI.

I've considered two ways to write compatible string naming.

Option 1: Use a single SoC-specific compatible string

Rename "realtek,misc" to "realtek,rtd1861-misc"

/* kent.dtsi */
misc: syscon@... {
    compatible = "realtek,rtd1861-misc", "syscon", "simple-mfd"; };

Pros: Only one compatible string is needed, simplifying maintenance
across the driver and DTS.

Cons: Violates the "SoC-specific compatible" rule for other SoCs
(RTD1501, RTD1920).

Option 2: SoC-specific + fallback (Compliant but Verbose)

Define the full list in the schema, and override the compatible string in each

SoC DTSI.

quoted

/* schema binding */

compatible:
  items:
    - enum:
        - realtek,rtd1501-misc
        - realtek,rtd1861-misc
        - realtek,rtd1920-misc
        # ... add new SoCs here
    - const: realtek,kent-misc
    - const: syscon
    - const: simple-mfd


/* kent.dtsi */

misc: syscon@... {
    compatible = "realtek,kent-misc", "syscon", "simple-mfd"; };

SoC-specific override (e.g. rtd1920s-smallville.dtsi):

&misc {
    compatible = "realtek,rtd1920-misc", "realtek,kent-misc", "syscon",
                 "simple-mfd";
};

Pros: Fully compliant with DT rules

Cons: Requires override in every SoC file; slight duplication.

Is Option 2 the expected pattern?
Thanks for your guidance!

None of them. You need SoC specific compatibles which can be used as
fallbacks for SoC specific compatibles. There is plenty of examples for this
already, but anyway this does not solve the problem that you still did not
properly describe the hardware but instead use your downstream as
arguments.

This will get you nowhere.

To implement this fallback structure, my understanding is that the
SoC-level DTSI should override the node and prepend its SoC-specific
Compatible, while the common DTSI only provides the family-level
compatible.

/* common DTSI */
misc: syscon@... {
    compatible = "realtek,kent-misc", "syscon", "simple-mfd";
};

/* SoC-specific DTSI */
&misc {
    compatible = "realtek,rtd1920-misc",
                 "realtek,kent-misc",
                 "syscon", "simple-mfd";
};
Please let me know if this is the intended usage.

Best regards,
Krzysztof