[PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

The reported problem of some non-working UHS-I speed modes on SM8450
originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
SDHCI SDR104/SDR50 on all boards").

The tests show that the rootcause of the problem was related to an
overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").

Due to a missed setting of an appropriate SDCC clock operations in
platform GCC driver the workaround of dropping SD card speeds from UHS-I
to high speed was spread to SM8550 and SM8650 platforms, and since
the fixes in the clock controller drivers are ready [1], it should be
safe to remove the speed mode restrictions from SM8450, SM8550 and
SM8650 platforms.

[1] https://lore.kernel.org/linux-arm-msm/20251124212012.3660189-1-vladimir.zapolskiy@linaro.org/

Vladimir Zapolskiy (3):
  arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes
  arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes
  arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes

 arch/arm64/boot/dts/qcom/sm8450.dtsi | 3 ---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 3 ---
 3 files changed, 9 deletions(-)

-- 
2.49.0

[PATCH 1/3] arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

The reported problem of some non-working UHS-I speed modes on SM8450
originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
SDHCI SDR104/SDR50 on all boards").

The tests show that the rootcause of the problem was related to an
overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").

Since then both SDR50 and SDR104 speed modes are working fine on SM8450,
tested on SM8450-HDK:

SDR50 speed mode:

    mmc0: new UHS-I speed SDR50 SDHC card at address 0001
    mmcblk0: mmc0:0001 00000 14.6 GiB
     mmcblk0: p1

    % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s

SDR104 speed mode:

    mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
    mmcblk0: mmc0:59b4 USDU1 28.3 GiB
     mmcblk0: p1

    % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s

Remove the restrictions on SD card speed modes from the SM8450 platform
dtsi file and enable UHS-I speed modes.

Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8450.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
index 23420e692472..fc4b7bc04532 100644
--- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
@@ -5404,9 +5404,6 @@ sdhc_2: mmc@8804000 {
 			bus-width = <4>;
 			dma-coherent;
 
-			/* Forbid SDR104/SDR50 - broken hw! */
-			sdhci-caps-mask = <0x3 0x0>;
-
 			status = "disabled";
 
 			sdhc2_opp_table: opp-table {
-- 
2.49.0

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes

[Neil Armstrong]

On 11/26/25 02:20, Vladimir Zapolskiy wrote:
> The reported problem of some non-working UHS-I speed modes on SM8450
> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
> SDHCI SDR104/SDR50 on all boards").
> 
> The tests show that the rootcause of the problem was related to an
> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
> 
> Since then both SDR50 and SDR104 speed modes are working fine on SM8450,
> tested on SM8450-HDK:
> 
> SDR50 speed mode:
> 
>      mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>      mmcblk0: mmc0:0001 00000 14.6 GiB
>       mmcblk0: p1
> 
>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>      1024+0 records in
>      1024+0 records out
>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.6254 s, 43.6 MB/s
> 
> SDR104 speed mode:
> 
>      mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>      mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>       mmcblk0: p1
> 
>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>      1024+0 records in
>      1024+0 records out
>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.3266 s, 87.1 MB/s
> 
> Remove the restrictions on SD card speed modes from the SM8450 platform
> dtsi file and enable UHS-I speed modes.
> 
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/sm8450.dtsi | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 23420e692472..fc4b7bc04532 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -5404,9 +5404,6 @@ sdhc_2: mmc@8804000 {
>   			bus-width = <4>;
>   			dma-coherent;
>   
> -			/* Forbid SDR104/SDR50 - broken hw! */
> -			sdhci-caps-mask = <0x3 0x0>;
> -
>   			status = "disabled";
>   
>   			sdhc2_opp_table: opp-table {

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Enable UHS-I SDR50 and SDR104 SD card modes

[Konrad Dybcio]

On 11/26/25 2:20 AM, Vladimir Zapolskiy wrote:
> The reported problem of some non-working UHS-I speed modes on SM8450
> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
> SDHCI SDR104/SDR50 on all boards").
> 
> The tests show that the rootcause of the problem was related to an
> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
> 
> Since then both SDR50 and SDR104 speed modes are working fine on SM8450,
> tested on SM8450-HDK:

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH 2/3] arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

The restriction on UHS-I speed modes was added to all SM8550 platforms
by copying it from SM8450 dtsi file, and due to the overclocking of SD
cards it was an actually reproducible problem. Since the latter issue
has been fixed, UHS-I speed modes are working fine on SM8550 boards,
below is the test performed on SM8550-HDK:

SDR50 speed mode:

    mmc0: new UHS-I speed SDR50 SDHC card at address 0001
    mmcblk0: mmc0:0001 00000 14.6 GiB
     mmcblk0: p1

    % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s

SDR104 speed mode:

    mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
    mmcblk0: mmc0:59b4 USDU1 28.3 GiB
     mmcblk0: p1

    % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s

Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
file, there is no indication that the SDHC controller is broken.

Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 7724dba75db7..7f5a8574059f 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -3191,9 +3191,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 			bus-width = <4>;
 			dma-coherent;
 
-			/* Forbid SDR104/SDR50 - broken hw! */
-			sdhci-caps-mask = <0x3 0>;
-
 			status = "disabled";
 
 			sdhc2_opp_table: opp-table {
-- 
2.49.0

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes

[Neil Armstrong]

On 11/26/25 02:20, Vladimir Zapolskiy wrote:
> The restriction on UHS-I speed modes was added to all SM8550 platforms
> by copying it from SM8450 dtsi file, and due to the overclocking of SD
> cards it was an actually reproducible problem. Since the latter issue
> has been fixed, UHS-I speed modes are working fine on SM8550 boards,
> below is the test performed on SM8550-HDK:
> 
> SDR50 speed mode:
> 
>      mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>      mmcblk0: mmc0:0001 00000 14.6 GiB
>       mmcblk0: p1
> 
>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>      1024+0 records in
>      1024+0 records out
>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s
> 
> SDR104 speed mode:
> 
>      mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>      mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>       mmcblk0: p1
> 
>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>      1024+0 records in
>      1024+0 records out
>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s
> 
> Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
> file, there is no indication that the SDHC controller is broken.
> 
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/sm8550.dtsi | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index 7724dba75db7..7f5a8574059f 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -3191,9 +3191,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>   			bus-width = <4>;
>   			dma-coherent;
>   
> -			/* Forbid SDR104/SDR50 - broken hw! */
> -			sdhci-caps-mask = <0x3 0>;
> -
>   			status = "disabled";
>   
>   			sdhc2_opp_table: opp-table {

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes

[Konrad Dybcio]

On 11/26/25 2:20 AM, Vladimir Zapolskiy wrote:
> The restriction on UHS-I speed modes was added to all SM8550 platforms
> by copying it from SM8450 dtsi file, and due to the overclocking of SD
> cards it was an actually reproducible problem. Since the latter issue
> has been fixed, UHS-I speed modes are working fine on SM8550 boards,
> below is the test performed on SM8550-HDK:
> 
> SDR50 speed mode:
> 
>     mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>     mmcblk0: mmc0:0001 00000 14.6 GiB
>      mmcblk0: p1
> 
>     % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>     1024+0 records in
>     1024+0 records out
>     1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s
> 
> SDR104 speed mode:
> 
>     mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>     mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>      mmcblk0: p1
> 
>     % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>     1024+0 records in
>     1024+0 records out
>     1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s
> 
> Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
> file, there is no indication that the SDHC controller is broken.
> 
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---

8550 has additional limitations. One was addressed recently with
max-sd-hs-hz (HS mode can only run at 37.5 MHz), but when in SDR104,
the frequency must also be capped to 148 MHz. I don't know whether
the driver respects that today.

Konrad

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

Hi Konrad.

On 11/27/25 15:40, Konrad Dybcio wrote:
> On 11/26/25 2:20 AM, Vladimir Zapolskiy wrote:
>> The restriction on UHS-I speed modes was added to all SM8550 platforms
>> by copying it from SM8450 dtsi file, and due to the overclocking of SD
>> cards it was an actually reproducible problem. Since the latter issue
>> has been fixed, UHS-I speed modes are working fine on SM8550 boards,
>> below is the test performed on SM8550-HDK:
>>
>> SDR50 speed mode:
>>
>>      mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>>      mmcblk0: mmc0:0001 00000 14.6 GiB
>>       mmcblk0: p1
>>
>>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>>      1024+0 records in
>>      1024+0 records out
>>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s
>>
>> SDR104 speed mode:
>>
>>      mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>>      mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>>       mmcblk0: p1
>>
>>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>>      1024+0 records in
>>      1024+0 records out
>>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s
>>
>> Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
>> file, there is no indication that the SDHC controller is broken.
>>
>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>> ---
> 
> 8550 has additional limitations. One was addressed recently with
> max-sd-hs-hz (HS mode can only run at 37.5 MHz), but when in SDR104,
> the frequency must also be capped to 148 MHz. I don't know whether
> the driver respects that today.
> 

This frequency cap tuning for SDR104 speed mode is not done. If I
remember the story properly, the frequency cap for HS speed mode was
implemented in dts instead of being a pure Qualcomm SDHC specific
quirk, because it's possible to workaround the limitation by slightly
changing a board PCB layout. Then should this new SDR104 quirk be
considered due to a property in the dtb as well?

FWIW, comparing register dumps SD host controllers on SM8550 and SM8650
SoCs are identical, should HS and SDR104 quirks be ported to SM8650 also?

Thank you a lot for reviews and hints!

-- 
Best wishes,
Vladimir

Re: [PATCH 2/3] arm64: dts: qcom: sm8550: Enable UHS-I SDR50 and SDR104 SD card modes

[Konrad Dybcio]

On 11/27/25 3:27 PM, Vladimir Zapolskiy wrote:
> Hi Konrad.
> 
> On 11/27/25 15:40, Konrad Dybcio wrote:
>> On 11/26/25 2:20 AM, Vladimir Zapolskiy wrote:
>>> The restriction on UHS-I speed modes was added to all SM8550 platforms
>>> by copying it from SM8450 dtsi file, and due to the overclocking of SD
>>> cards it was an actually reproducible problem. Since the latter issue
>>> has been fixed, UHS-I speed modes are working fine on SM8550 boards,
>>> below is the test performed on SM8550-HDK:
>>>
>>> SDR50 speed mode:
>>>
>>>      mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>>>      mmcblk0: mmc0:0001 00000 14.6 GiB
>>>       mmcblk0: p1
>>>
>>>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>>>      1024+0 records in
>>>      1024+0 records out
>>>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.5468 s, 45.6 MB/s
>>>
>>> SDR104 speed mode:
>>>
>>>      mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>>>      mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>>>       mmcblk0: p1
>>>
>>>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>>>      1024+0 records in
>>>      1024+0 records out
>>>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 11.9819 s, 89.6 MB/s
>>>
>>> Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
>>> file, there is no indication that the SDHC controller is broken.
>>>
>>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>>> ---
>>
>> 8550 has additional limitations. One was addressed recently with
>> max-sd-hs-hz (HS mode can only run at 37.5 MHz), but when in SDR104,
>> the frequency must also be capped to 148 MHz. I don't know whether
>> the driver respects that today.
>>
> 
> This frequency cap tuning for SDR104 speed mode is not done. If I
> remember the story properly, the frequency cap for HS speed mode was
> implemented in dts instead of being a pure Qualcomm SDHC specific
> quirk, because it's possible to workaround the limitation by slightly
> changing a board PCB layout. Then should this new SDR104 quirk be
> considered due to a property in the dtb as well?

I think so.

> FWIW, comparing register dumps SD host controllers on SM8550 and SM8650
> SoCs are identical, should HS and SDR104 quirks be ported to SM8650 also?

A document says that in 8650 and 8750 (and hamoa) and newer, these issues
are not present, however the original author added the same limitation to
sm8750:

https://lore.kernel.org/linux-arm-msm/20251026111746.3195861-3-sarthak.garg@oss.qualcomm.com/

+Sarthak could you please remind us why it'd be necessary on !8550?

Konrad

[PATCH 3/3] arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

The restriction on UHS-I speed modes was added to all SM8650 platforms
by copying it from SM8450 and SM8550 dtsi files, and it was an actually
reproducible problem due to the overclocking of SD cards. Since the latter
issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are
working fine on SM8650 boards, below is the test performed on SM8650-HDK:

SDR50 speed mode:

    mmc0: new UHS-I speed SDR50 SDHC card at address 0001
    mmcblk0: mmc0:0001 00000 14.6 GiB
     mmcblk0: p1

    % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s

    SDR104 speed mode:

    mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
    mmcblk0: mmc0:59b4 USDU1 28.3 GiB
     mmcblk0: p1

    % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
    1024+0 records in
    1024+0 records out
    1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s

Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
file, there is no indication that the SDHC controller is broken.

Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index ebf1971b1bfb..1be709204cae 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -4939,9 +4939,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 
 			bus-width = <4>;
 
-			/* Forbid SDR104/SDR50 - broken hw! */
-			sdhci-caps-mask = <0x3 0>;
-
 			qcom,dll-config = <0x0007642c>;
 			qcom,ddr-config = <0x80040868>;
 
-- 
2.49.0

Re: [PATCH 3/3] arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes

[Neil Armstrong]

On 11/26/25 02:20, Vladimir Zapolskiy wrote:
> The restriction on UHS-I speed modes was added to all SM8650 platforms
> by copying it from SM8450 and SM8550 dtsi files, and it was an actually
> reproducible problem due to the overclocking of SD cards. Since the latter
> issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are
> working fine on SM8650 boards, below is the test performed on SM8650-HDK:
> 
> SDR50 speed mode:
> 
>      mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>      mmcblk0: mmc0:0001 00000 14.6 GiB
>       mmcblk0: p1
> 
>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>      1024+0 records in
>      1024+0 records out
>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s
> 
>      SDR104 speed mode:
> 
>      mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>      mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>       mmcblk0: p1
> 
>      % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>      1024+0 records in
>      1024+0 records out
>      1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s
> 
> Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
> file, there is no indication that the SDHC controller is broken.
> 
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/sm8650.dtsi | 3 ---
>   1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index ebf1971b1bfb..1be709204cae 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -4939,9 +4939,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>   
>   			bus-width = <4>;
>   
> -			/* Forbid SDR104/SDR50 - broken hw! */
> -			sdhci-caps-mask = <0x3 0>;
> -
>   			qcom,dll-config = <0x0007642c>;
>   			qcom,ddr-config = <0x80040868>;
>   

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Re: [PATCH 3/3] arm64: dts: qcom: sm8650: Enable UHS-I SDR50 and SDR104 SD card modes

[Konrad Dybcio]

On 11/26/25 2:20 AM, Vladimir Zapolskiy wrote:
> The restriction on UHS-I speed modes was added to all SM8650 platforms
> by copying it from SM8450 and SM8550 dtsi files, and it was an actually
> reproducible problem due to the overclocking of SD cards. Since the latter
> issue has been fixed in the SM8650 GCC driver, UHS-I speed modes are
> working fine on SM8650 boards, below is the test performed on SM8650-HDK:
> 
> SDR50 speed mode:
> 
>     mmc0: new UHS-I speed SDR50 SDHC card at address 0001
>     mmcblk0: mmc0:0001 00000 14.6 GiB
>      mmcblk0: p1
> 
>     % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>     1024+0 records in
>     1024+0 records out
>     1073741824 bytes (1.1 GB, 1.0 GiB) copied, 24.8086 s, 43.3 MB/s
> 
>     SDR104 speed mode:
> 
>     mmc0: new UHS-I speed SDR104 SDHC card at address 59b4
>     mmcblk0: mmc0:59b4 USDU1 28.3 GiB
>      mmcblk0: p1
> 
>     % dd if=/dev/mmcblk0p1 of=/dev/null bs=1M count=1024
>     1024+0 records in
>     1024+0 records out
>     1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.9448 s, 82.9 MB/s
> 
> Unset the UHS-I speed mode restrictions from the SM8550 platform dtsi
> file, there is no indication that the SDHC controller is broken.
> 
> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index ebf1971b1bfb..1be709204cae 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -4939,9 +4939,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>  
>  			bus-width = <4>;
>  
> -			/* Forbid SDR104/SDR50 - broken hw! */

This comment wasn't even right.. it did forbid MMC_CAP_4_BIT_DATA
which seems to have knocked off UHS-I for good, but also MMC_CAP_MMC_HIGHSPEED
which isn't applicable to SD cards

in any case

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Val Packett]

Hi,

On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
> The reported problem of some non-working UHS-I speed modes on SM8450
> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
> SDHCI SDR104/SDR50 on all boards").
>
> The tests show that the rootcause of the problem was related to an
> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>
> Due to a missed setting of an appropriate SDCC clock operations in
> platform GCC driver the workaround of dropping SD card speeds from UHS-I
> to high speed was spread to SM8550 and SM8650 platforms, and since
> the fixes in the clock controller drivers are ready [1], it should be
> safe to remove the speed mode restrictions from SM8450, SM8550 and
> SM8650 platforms.
> [..]

I see you have tested with dd on the raw block device, but have you 
tested hotplugging SD cards that have partition tables and filesystems 
on them?

We have this kind of issue on Hamoa where we get I/O errors early, right 
after the card is inserted and the partition table / filesystem headers 
are being read:

[  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
[  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
[  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 
phys_seg 1 prio class 2
[  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async 
page read
[  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 
phys_seg 1 prio class 2
[  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async 
page read
[  714.516512]  mmcblk0: unable to read partition table

and b1f856b1727c ("mmc: sdhci-msm: Avoid early clock doubling during 
HS400 transition") did not help..


~val

Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

Hi Val,

On 11/26/25 18:14, Val Packett wrote:
> Hi,
> 
> On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
>> The reported problem of some non-working UHS-I speed modes on SM8450
>> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
>> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
>> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
>> SDHCI SDR104/SDR50 on all boards").
>>
>> The tests show that the rootcause of the problem was related to an
>> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
>> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>>
>> Due to a missed setting of an appropriate SDCC clock operations in
>> platform GCC driver the workaround of dropping SD card speeds from UHS-I
>> to high speed was spread to SM8550 and SM8650 platforms, and since
>> the fixes in the clock controller drivers are ready [1], it should be
>> safe to remove the speed mode restrictions from SM8450, SM8550 and
>> SM8650 platforms.
>> [..]
> 
> I see you have tested with dd on the raw block device, but have you
> tested hotplugging SD cards that have partition tables and filesystems
> on them?

the test results given in the commit message are for demonstation purpose,
the test do serve right the same purpose of performing I/O reading from
an SD card as reading a partition table.

An important point is that if there are some issues with a filesystem on
SD card, it just lacks a justification of "forbidding SDR104/SDR50 due
broken SDHC hardware".

> We have this kind of issue on Hamoa where we get I/O errors early, right
> after the card is inserted and the partition table / filesystem headers
> are being read:

Hamoa is X1E80100, is it right? Unfortunately I can not test my set of
SD cards including one Transcend UHS-I SDR104 speed mode SD card on this
particular hardware.

> [  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
> [  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
> [  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0
> phys_seg 1 prio class 2
> [  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async
> page read
> [  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0
> phys_seg 1 prio class 2
> [  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async
> page read
> [  714.516512]  mmcblk0: unable to read partition table
> 
> and b1f856b1727c ("mmc: sdhci-msm: Avoid early clock doubling during
> HS400 transition") did not help..
> 

I've checked that this particular change [1], and it's unlikely that it
has an impact on the issue reported above due to the fact that the
problem is reported against an UHS-I SDR104 SD card, and the fix does
not touch this mode. So, it's kind of expected, and for further analysis
I need more information.

Note what is the originally reported problem, which workaround is supposed
to be reverted now:

9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable SDHCI SDR104/SDR50 on all boards"):

       mmc0: card never left busy state
       mmc0: error -110 whilst initialising SD card

This is very different from your fault report, and this is fixed by
my recent changes in the SM8x50 GCC drivers, and this one series
setteles the fix.

[1] https://lore.kernel.org/linux-mmc/20251114082824.3825501-1-sarthak.garg@oss.qualcomm.com/

-- 
Best wishes,
Vladimir

Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Konrad Dybcio]

On 11/26/25 5:14 PM, Val Packett wrote:
> Hi,
> 
> On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
>> The reported problem of some non-working UHS-I speed modes on SM8450
>> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
>> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
>> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
>> SDHCI SDR104/SDR50 on all boards").
>>
>> The tests show that the rootcause of the problem was related to an
>> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
>> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>>
>> Due to a missed setting of an appropriate SDCC clock operations in
>> platform GCC driver the workaround of dropping SD card speeds from UHS-I
>> to high speed was spread to SM8550 and SM8650 platforms, and since
>> the fixes in the clock controller drivers are ready [1], it should be
>> safe to remove the speed mode restrictions from SM8450, SM8550 and
>> SM8650 platforms.
>> [..]
> 
> I see you have tested with dd on the raw block device, but have you tested hotplugging SD cards that have partition tables and filesystems on them?
> 
> We have this kind of issue on Hamoa where we get I/O errors early, right after the card is inserted and the partition table / filesystem headers are being read:
> 
> [  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
> [  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
> [  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
> [  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async page read
> [  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
> [  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async page read
> [  714.516512]  mmcblk0: unable to read partition table

Before we start debugging, could you please confirm it's using the internal
(&sdhc_2) MMC controller, and not one connected over PCIe, like it's the
case on the Surface Laptop?

Are the regulators supplying vmmc and vqmmc in high power mode?

Konrad

Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Val Packett]

On 11/27/25 10:47 AM, Konrad Dybcio wrote:
> On 11/26/25 5:14 PM, Val Packett wrote:
>> Hi,
>>
>> On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
>>> The reported problem of some non-working UHS-I speed modes on SM8450
>>> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
>>> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
>>> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
>>> SDHCI SDR104/SDR50 on all boards").
>>>
>>> The tests show that the rootcause of the problem was related to an
>>> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
>>> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>>>
>>> Due to a missed setting of an appropriate SDCC clock operations in
>>> platform GCC driver the workaround of dropping SD card speeds from UHS-I
>>> to high speed was spread to SM8550 and SM8650 platforms, and since
>>> the fixes in the clock controller drivers are ready [1], it should be
>>> safe to remove the speed mode restrictions from SM8450, SM8550 and
>>> SM8650 platforms.
>>> [..]
>> I see you have tested with dd on the raw block device, but have you tested hotplugging SD cards that have partition tables and filesystems on them?
>>
>> We have this kind of issue on Hamoa where we get I/O errors early, right after the card is inserted and the partition table / filesystem headers are being read:
>>
>> [  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
>> [  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
>> [  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>> [  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>> [  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>> [  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>> [  714.516512]  mmcblk0: unable to read partition table
> Before we start debugging, could you please confirm it's using the internal
> (&sdhc_2) MMC controller, and not one connected over PCIe, like it's the
> case on the Surface Laptop?
Of course it is. I'm quite familiar with the DTS on this device, I 
pushed it over the finish line into upstream myself :)
> Are the regulators supplying vmmc and vqmmc in high power mode?

Yes. regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; and no 
allow-set-load / allowed-modes (..hm, maybe we can actually add those to 
save power since sdhci-msm *does* do regulator_set_load..)

But turns out this is not a consistent problem with every card!.. At 
least *now* one of the two Kingston Canvas Select Plus cards I have 
attaches perfectly every time. (Another one of those though often fails 
to probe with "error -84 reading general info of SD ext reg" and 
sometimes has an early I/O error, but exFAT mounts even after that error 
— but this seems like just a "microSD cards are crap" thing.)

It's the Samsung Evo Plus card that consistently has early I/O errors 
preventing the partition table scan from succeeding (or if that 
succeeds, prevents the exFAT mount). There is a *card compat* issue here 
for sure, as the card is not corrupted, it mounts every time on a 
different laptop with a PCIe card reader [1217:8621] in the same SDR104 
mode. But consistently has these errors on sdhci-msm.

Thanks,
~val

Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Vladimir Zapolskiy]

On 11/27/25 21:33, Val Packett wrote:
> On 11/27/25 10:47 AM, Konrad Dybcio wrote:
>> On 11/26/25 5:14 PM, Val Packett wrote:
>>> Hi,
>>>
>>> On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
>>>> The reported problem of some non-working UHS-I speed modes on SM8450
>>>> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
>>>> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
>>>> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
>>>> SDHCI SDR104/SDR50 on all boards").
>>>>
>>>> The tests show that the rootcause of the problem was related to an
>>>> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
>>>> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>>>>
>>>> Due to a missed setting of an appropriate SDCC clock operations in
>>>> platform GCC driver the workaround of dropping SD card speeds from UHS-I
>>>> to high speed was spread to SM8550 and SM8650 platforms, and since
>>>> the fixes in the clock controller drivers are ready [1], it should be
>>>> safe to remove the speed mode restrictions from SM8450, SM8550 and
>>>> SM8650 platforms.
>>>> [..]
>>> I see you have tested with dd on the raw block device, but have you tested hotplugging SD cards that have partition tables and filesystems on them?
>>>
>>> We have this kind of issue on Hamoa where we get I/O errors early, right after the card is inserted and the partition table / filesystem headers are being read:
>>>
>>> [  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
>>> [  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
>>> [  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>>> [  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>>> [  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>>> [  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>>> [  714.516512]  mmcblk0: unable to read partition table
>> Before we start debugging, could you please confirm it's using the internal
>> (&sdhc_2) MMC controller, and not one connected over PCIe, like it's the
>> case on the Surface Laptop?
> Of course it is. I'm quite familiar with the DTS on this device, I
> pushed it over the finish line into upstream myself :)
>> Are the regulators supplying vmmc and vqmmc in high power mode?
> 
> Yes. regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; and no
> allow-set-load / allowed-modes (..hm, maybe we can actually add those to
> save power since sdhci-msm *does* do regulator_set_load..)
> 
> But turns out this is not a consistent problem with every card!.. At
> least *now* one of the two Kingston Canvas Select Plus cards I have
> attaches perfectly every time. (Another one of those though often fails
> to probe with "error -84 reading general info of SD ext reg" and
> sometimes has an early I/O error, but exFAT mounts even after that error
> — but this seems like just a "microSD cards are crap" thing.)
> 
> It's the Samsung Evo Plus card that consistently has early I/O errors
> preventing the partition table scan from succeeding (or if that

For the last 10 years it's known that a multitude of Samsung Evo SD cards
are fake.

> succeeds, prevents the exFAT mount). There is a *card compat* issue here
> for sure, as the card is not corrupted, it mounts every time on a
> different laptop with a PCIe card reader [1217:8621] in the same SDR104
> mode. But consistently has these errors on sdhci-msm.
> 

Please check the actual I/O speed of this card on a host, the given dd
command should be sufficient for that purpose. It might happen that if
the actually supported max speed is not close to SDR104, however the mode
is set by the Qualcomm SDHC driver due to info read from the card out,
the I/O may be faulty.

-- 
Best wishes,
Vladimir

Re: [PATCH 0/3] arm64: dts: qcom: sm8x50: Enable UHS-I SDR50 and SDR104 SD card modes

[Konrad Dybcio]

On 11/27/25 8:33 PM, Val Packett wrote:
> 
> On 11/27/25 10:47 AM, Konrad Dybcio wrote:
>> On 11/26/25 5:14 PM, Val Packett wrote:
>>> Hi,
>>>
>>> On 11/25/25 10:20 PM, Vladimir Zapolskiy wrote:
>>>> The reported problem of some non-working UHS-I speed modes on SM8450
>>>> originates in commit 0a631a36f724 ("arm64: dts: qcom: Add device tree
>>>> for Sony Xperia 1 IV"), and then it was spread to all SM8450 powered
>>>> platforms by commit 9d561dc4e5cc ("arm64: dts: qcom: sm8450: disable
>>>> SDHCI SDR104/SDR50 on all boards").
>>>>
>>>> The tests show that the rootcause of the problem was related to an
>>>> overclocking of SD cards, and it's fixed later on by commit a27ac3806b0a
>>>> ("clk: qcom: gcc-sm8450: Use floor ops for SDCC RCGs").
>>>>
>>>> Due to a missed setting of an appropriate SDCC clock operations in
>>>> platform GCC driver the workaround of dropping SD card speeds from UHS-I
>>>> to high speed was spread to SM8550 and SM8650 platforms, and since
>>>> the fixes in the clock controller drivers are ready [1], it should be
>>>> safe to remove the speed mode restrictions from SM8450, SM8550 and
>>>> SM8650 platforms.
>>>> [..]
>>> I see you have tested with dd on the raw block device, but have you tested hotplugging SD cards that have partition tables and filesystems on them?
>>>
>>> We have this kind of issue on Hamoa where we get I/O errors early, right after the card is inserted and the partition table / filesystem headers are being read:
>>>
>>> [  714.057106] mmc0: new UHS-I speed SDR104 SDXC card at address 0001
>>> [  714.060567] mmcblk0: mmc0:0001 EC2QT 59.6 GiB
>>> [  714.503873] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>>> [  714.505660] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>>> [  714.513632] I/O error, dev mmcblk0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
>>> [  714.516469] Buffer I/O error on dev mmcblk0, logical block 0, async page read
>>> [  714.516512]  mmcblk0: unable to read partition table
>> Before we start debugging, could you please confirm it's using the internal
>> (&sdhc_2) MMC controller, and not one connected over PCIe, like it's the
>> case on the Surface Laptop?
> Of course it is. I'm quite familiar with the DTS on this device, I pushed it over the finish line into upstream myself :)
>> Are the regulators supplying vmmc and vqmmc in high power mode?
> 
> Yes. regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>; and no allow-set-load / allowed-modes (..hm, maybe we can actually add those to save power since sdhci-msm *does* do regulator_set_load..)
> 
> But turns out this is not a consistent problem with every card!.. At least *now* one of the two Kingston Canvas Select Plus cards I have attaches perfectly every time. (Another one of those though often fails to probe with "error -84 reading general info of SD ext reg" and sometimes has an early I/O error, but exFAT mounts even after that error — but this seems like just a "microSD cards are crap" thing.)
> 
> It's the Samsung Evo Plus card that consistently has early I/O errors preventing the partition table scan from succeeding (or if that succeeds, prevents the exFAT mount). There is a *card compat* issue here for sure, as the card is not corrupted, it mounts every time on a different laptop with a PCIe card reader [1217:8621] in the same SDR104 mode. But consistently has these errors on sdhci-msm.

Would you happen to have access to a Snapdragon phone from a similar era?

Could you insert it there and see if you have any issues?

Konrad