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

["Yu-Chun Lin [林祐君]" <eleanor.lin@realtek.com>]

> 
> On 17/11/2025 12:03, Yu-Chun Lin [林祐君] wrote:
> > Hi Conor and Krzysztof,
> >
> >> 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.
> >
> > 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.

> 
> > 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.
> >
> > /* 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