linux-kernel - Re: [PATCH v2 1/2] dt-bindings: mmc: renesas,sdhi: Add mux-states property

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <7322ce79-4684-4a3e-9637-824b4398b51a@solid-run.com>
Date: Mon, 1 Dec 2025 14:00:32 +0000
From: Josua Mayer <josua@...id-run.com>
To: Biju Das <biju.das.jz@...renesas.com>, Ulf Hansson
	<ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
	<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Geert Uytterhoeven
	<geert+renesas@...der.be>, magnus.damm <magnus.damm@...il.com>, wsa+renesas
	<wsa+renesas@...g-engineering.com>
CC: Mikhail Anikin <mikhail.anikin@...id-run.com>, Yazan Shhady
	<yazan.shhady@...id-run.com>, Jon Nettleton <jon@...id-run.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: mmc: renesas,sdhi: Add mux-states
 property

Hi Biju,

Am 01.12.25 um 14:02 schrieb Biju Das:
> Hi Josua Mayer,
>
>
> Thanks for the patch.
>
>> -----Original Message-----
>> From: Josua Mayer <josua@...id-run.com>
>> Sent: 01 December 2025 12:31
>> Subject: [PATCH v2 1/2] dt-bindings: mmc: renesas,sdhi: Add mux-states property
>>
>> Add mux controller support for when sdio lines are muxed between a host and multiple cards.
>>
>> There are several devices supporting a choice of eMMC or SD on a single board by both dip switch and
>> gpio, e.g. Renesas RZ/G2L SMARC SoM and SolidRun RZ/G2L SoM.
>>
>> In-tree dts for the Renesas boards currently rely on preprocessor macros to hog gpios and define the
>> card.
>>
>> By adding mux-states property to sdio controller description, boards can correctly describe the mux
>> that already exists in hardware - and drivers can coordinate between mux selection and probing for
>> cards.
>> Signed-off-by: Josua Mayer <josua@...id-run.com>
>> ---
>>  Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
>> b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
>> index c754ea71f51f7..754ccb1c30efb 100644
>> --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
>> @@ -106,6 +106,11 @@ properties:
>>    iommus:
>>      maxItems: 1
>>
>> +  mux-states:
>> +    description:
>> +      mux controller node to route the SDIO signals from SoC to cards.
> Maybe describe 0 - state for SD and 1 - state for eMMC ??
The state-mmc-sd mapping depends on the wiring and description
of the mux, so we cannot differentiate in the mux-states property.

The idea is that whatever numeric argument you add to the phandle
will select a particular state for the mux.
The rest of dt properties must still be specific to SD or eMMC, e.g.:

&sdhi0 {
    pinctrl-0 = <&sdhi0_pins>, <&sdhi0_cd_pins>;
    pinctrl-1 = <&sdhi0_uhs_pins>, <&sdhi0_cd_pins>;
    pinctrl-names = "default", "state_uhs";
    vmmc-supply = <&vmmc>;
    vqmmc-supply = <&reg_pmic_ldo1>;
    bus-width = <4>;
    sd-uhs-sdr50;
    sd-uhs-sdr104;
    full-pwr-cycle;
    mux-states = <&sdhi0_mux 1>;
    status = "okay";
};

>
>
>> +    maxItems: 1
>> +
>>    power-domains:
>>      maxItems: 1
>>
>> @@ -275,6 +280,7 @@ examples:
>>          max-frequency = <195000000>;
>>          power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
>>          resets = <&cpg 314>;
>> +        mux-states = <&mux 0>;
> On R-Car mmc/sd mux available only on SD2/SD3, so I guess you picked wrong node SD0??
As they were examples I did not give it much thought,
We could even omit mux-states from examples completely since it is optional.
>
> or 
>
> Add separate example with RZ/G2L, as the boards(RZ/G2L SMARC EVK)
> use gpio/switch (XOR function) to select the eMMC or SD signals??

I can if so desired add verbose example from our own G2L based board, e.g.:

sdhi0: mmc@...00000 {
    compatible = "renesas,sdhi-r9a07g044", "renesas,rzg2l-sdhi";
    reg = <0x0 0x11c00000 0 0x10000>;
    interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&cpg CPG_MOD R9A07G044_SDHI0_IMCLK>,
         <&cpg CPG_MOD R9A07G044_SDHI0_CLK_HS>,
         <&cpg CPG_MOD R9A07G044_SDHI0_IMCLK2>,
         <&cpg CPG_MOD R9A07G044_SDHI0_ACLK>;
    clock-names = "core", "clkh", "cd", "aclk";
    resets = <&cpg R9A07G044_SDHI0_IXRST>;
    power-domains = <&cpg>;
    pinctrl-0 = <&sdhi0_pins>, <&sdhi0_cd_pins>;
    pinctrl-1 = <&sdhi0_uhs_pins>, <&sdhi0_cd_pins>;
    pinctrl-names = "default", "state_uhs";
    vmmc-supply = <&vmmc>;
    vqmmc-supply = <&reg_pmic_ldo1>;
    bus-width = <4>;
    sd-uhs-sdr50;
    sd-uhs-sdr104;
    full-pwr-cycle;
    mux-states = <&sdhi0_mux 1>;
};

I do not believe however that this is adding any value.