linux-kernel - Re: [PATCH] riscv: dts: starfive: jh7110-common: drop no-sdio property from mmc1

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: <43c5908c-c478-4e00-b1e5-955296e4ec24@freeshell.de>
Date: Thu, 24 Jul 2025 22:13:47 -0700
From: E Shattow <e@...eshell.de>
To: Conor Dooley <conor@...nel.org>
Cc: Emil Renner Berthing <kernel@...il.dk>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, William Qiu <william.qiu@...rfivetech.com>,
 linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: dts: starfive: jh7110-common: drop no-sdio
 property from mmc1

Hi Conor,

On 7/24/25 09:51, Conor Dooley wrote:
> On Thu, Jul 24, 2025 at 12:55:53AM -0700, E Shattow wrote:
>> Drop no-sdio property avoids a delete-property on variant board dts
>> having an SDIO wireless module connected to mmc1.
> 
> I'm struggling to understand why this change is correct.
> 
> If there are specific boards that have wireless modules connected
> instead of using sdcards, how come the no-sdio property isn't moved to the
> the boards that do have sdcard slots?

Why is 'no-sdio' property there to begin with...

> The property was added for the visionfive 2, and only on mmc1, so should
> it be retained for boards that match the visionfive 2 in terms of how
> they use mmc?

Ref.:
https://lore.kernel.org/lkml/20221207131731.1291517-4-william.qiu@starfivetech.com/

My theory is VisionFive2 board hardware can support connecting up some
SDIO module there with ready-made available adapters, it may be possible
(if unusual) that would work? SDIO is 4-wide and some voltage
requirements, and a couple of GPIO, so I'm aware that's a stretch of a
statement but it could be done without soldering. I wouldn't expect it,
but why restrict this everywhere inheriting from jh7110-common.dtsi with
'no-sdio' and then (needs testing!) if it doesn't matter one way or the
other for VisionFive2 just drop it I think as being inaccurate/unnecessary?

JH7110 CPU supports two interfaces of SDIO3.0/eMMC so it's not clear to
me if there's some reason for 'no-sdio' property to be there. Does
allowing SDIO (?) break eMMC and SD Card devices, is it destructive?

Not knowing what 'no-sdio' does technically I dropped the property and
tested with the hardware I do have. The 'no-sdio' property
present/absent does not appear to do anything user-impactful on Pine64
Star64 that has SD Card slot on mmc1, and as would be expected on Milk-V
Mars CM Lite WiFi when there's an SDIO module at mmc1 it then fails to
initialize if 'no-sdio' property is present.

> 
> Could you add an explanation for why removing this entirely is the right
> thing to do, rather than only removing it for these variant boards?

Yes, I can rephrase a bit like "relax no-sdio restriction on mmc1 for
jh7110 boards", or else reconsider the approach. I was going to approach
with `/delete-property/ no-sdio;` later elsewhere but after testing on
Pine64 Star64 with similar configuration to VisionFive2 mmc interfaces,
and knowing that Milk-V Mars CM Lite WiFi detects AP6256 SDIO peripheral
at mmc1 when this property is dropped (and with a few additional
things)... I prefer to reduce the problems that would need to be avoided.

I have done all the testing I can do with hardware I have. As-is it's
just like I wrote, we'll have to solicit some testing feedback on that
and wait to learn what this does for the other boards.

Aside, anyone want to chime in what is the utility of 'no-sdio'
property, how do you know from a schematic if it is appropriate, can it
be simply dropped as I suggest for JH7110 boards?

> 
> Cheers,
> Conor.

Thank you for reviewing! -E

> 
>>
>> Signed-off-by: E Shattow <e@...eshell.de>
>> ---
>>  arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
>> index 2eaf01775ef5..a315113840e5 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
>> +++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
>> @@ -299,7 +299,6 @@ &mmc1 {
>>  	assigned-clock-rates = <50000000>;
>>  	bus-width = <4>;
>>  	bootph-pre-ram;
>> -	no-sdio;
>>  	no-mmc;
>>  	cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>;
>>  	disable-wp;
>>
>> base-commit: 28fa0dcb571ab8f3be4d919f0e20e01d4e44bcb1
>> -- 
>> 2.50.0
>>