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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d2dbb700ce684ee4a4c4ca120ac5e4e4@realtek.com>
Date: Wed, 19 Nov 2025 06:46:23 +0000
From: Yu-Chun Lin [林祐君] <eleanor.lin@...ltek.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        "afaerber@...e.de"
	<afaerber@...e.de>,
        "robh@...nel.org" <robh@...nel.org>,
        "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "lee@...nel.org" <lee@...nel.org>,
        James Tai [戴志峰]
	<james.tai@...ltek.com>
CC: "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
        "linux-realtek-soc@...ts.infradead.org"
	<linux-realtek-soc@...ts.infradead.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        CY_Huang[黃鉦晏]
	<cy.huang@...ltek.com>,
        Stanley Chang[昌育德]
	<stanley_chang@...ltek.com>
Subject: RE: [PATCH v2 2/3] dt-bindings: mfd: Add Realtek MISC system
 controller

> On 17/11/2025 13:41, Yu-Chun Lin [林祐君] wrote:
> >>>
> >>
> >> 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";
> 
> No. You changed nothing. How does this differ from options I disagreed with?
> 
> Anyway, there is no such SoC as "kent" and I was clear - you need SoC
> compatibles.
> 
> Define what is your SoC first.
> 
> Best regards,
> Krzysztof

Hi Krzysztof,

Thank you for your response.

The original intention was to add a basic Kent device tree, but since the
'misc' node is currently empty. I will remove both this device node and
its corresponding YAML binding in v3.

After further consideration within our team, we have decided to add
power-domain and reboot-mode functionalities to the 'misc' node in the
future. And we will adhere to the SoC-specific compatible string binding
pattern, following this structure:

/* schema binding */
compatible:
  items:
    - enum:
        - realtek,rtd1501-misc
        - realtek,rtd1861-misc
        - realtek,rtd1920-misc
    - const: syscon
    - const: simple-mfd

/* SoC-specific Device Tree Source (e.g. rtd1920s.dtsi) */

&rbus {
  misc: syscon@...0 {
    compatible = "realtek,rtd1920-misc", "syscon", "simple-mfd";
    reg = <0x7000 0x1000>;
    ranges = <0x0 0x7000 0x1000>;
    #address-cells = <1>;
    #size-cells = <1>;
  };
};

Best regards,
Yu-Chun