Technically, the reset signal is active low - it's called RST_n after all.

But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
is set in the emmc. It is 0 per default.

For emmcs that have RST_n_FUNCTION=1 we failed like this:

	[    3.074480] mmc1: Failed to initialize a non-removable card

With this change they work normally.

Cc: stable@vger.kernel.org
Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
---
 arch/arm64/boot/dts/rockchip/px30-cobra.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
index b7e669d8ba4d..90751b04f95c 100644
--- a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
@@ -35,7 +35,7 @@ emmc_pwrseq: emmc-pwrseq {
 		compatible = "mmc-pwrseq-emmc";
 		pinctrl-0 = <&emmc_reset>;
 		pinctrl-names = "default";
-		reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
 	};
 
 	gpio-leds {
-- 
2.47.3

Am Dienstag, 12. Mai 2026, 11:22:09 Mitteleuropäische Sommerzeit schrieb Jakob Unterwurzacher:
> Technically, the reset signal is active low - it's called RST_n after all.
> 
> But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
> is set in the emmc. It is 0 per default.
> 
> For emmcs that have RST_n_FUNCTION=1 we failed like this:
> 
> 	[    3.074480] mmc1: Failed to initialize a non-removable card
> 
> With this change they work normally.
> 
> Cc: stable@vger.kernel.org
> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
> Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>

as Quentin remarked, author (@gmail) and signed-off-by do not match.
While I'm generally open to fixing things, when it touches the DCO this
isn't the case.

So please resend this with the correct author.

In general "git send-email" will do the correct thing (that From: line),
when patch author and email-id do not match.


Thanks
Heiko

> ---
>  arch/arm64/boot/dts/rockchip/px30-cobra.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
> index b7e669d8ba4d..90751b04f95c 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30-cobra.dtsi
> @@ -35,7 +35,7 @@ emmc_pwrseq: emmc-pwrseq {
>  		compatible = "mmc-pwrseq-emmc";
>  		pinctrl-0 = <&emmc_reset>;
>  		pinctrl-names = "default";
> -		reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
>  	};
>  
>  	gpio-leds {
> 

On 6/2/26 23:08, Heiko Stuebner wrote:
> 
> as Quentin remarked, author (@gmail) and signed-off-by do not match.
> While I'm generally open to fixing things, when it touches the DCO this
> isn't the case.
> 
> So please resend this with the correct author.
> 
> In general "git send-email" will do the correct thing (that From: line),
> when patch author and email-id do not match.

For posterity:

What seems to be happening is that Gmail rewrites the "From: " header on 
the server side. git send-email does now know this, so doesn't add the 
extra "From: " line.

Making the final "From: " explicit in .gitconfig using

[sendemail]
	from = Jakob Unterwurzacher <jakobunt@gmail.com>

now makes git send-email add that extra "From: " line in the email body 
as expected.

I'll resend the patch now.

Thanks, Jakob

Hi Jakob,

JFYI, the commit author will differ from the Signed-off-by (it's your 
gmail address that is going to appear as author).

Usually, when the mail From address is different from the commit author, 
there's a From: line as first line in the patch (which won't appear in 
the commit once merged). See 
https://lore.kernel.org/linux-rockchip/20260421-px30-eth-phy-v2-1-68c375b120fd@cherry.de/ 
for an example. Not sure what's happening with your setup :)

On 5/12/26 11:22 AM, Jakob Unterwurzacher wrote:
> Technically, the reset signal is active low - it's called RST_n after all.
> 
> But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
> is set in the emmc. It is 0 per default.
> 
> For emmcs that have RST_n_FUNCTION=1 we failed like this:
> 
> 	[    3.074480] mmc1: Failed to initialize a non-removable card
> 
> With this change they work normally.
> 
> Cc: stable@vger.kernel.org
> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")

This also matches the Device Tree bindings for eMMC MMC pwrseq devices, 
c.f. 
https://elixir.bootlin.com/linux/v7.0.5/source/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml#L33

Looking at their respective schematics and Device Tree, I think we also 
have the same issue on our Jaguar, PP-1516, Ringneck and Tiger, would 
you be so kind and check I read the schematics properly and send patches 
for those as well?

@Heiko, I've checked and it seems like (in addition to Jaguar, PP-1516, 
Ringneck and Tiger):

arch/arm/boot/dts/rockchip/rk3288-veyron.dtsi
arch/arm64/boot/dts/rockchip/rk3368-r88.dts
arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts
arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
arch/arm64/boot/dts/rockchip/px30-firefly-jd4-core.dtsi
arch/arm64/boot/dts/rockchip/px30-evb.dts

all have that wrong polarity (though, without access to the schematics, 
who knows if it's really supposed to be inverted polarity (e.g. because 
it's inverted via a transistor)).

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin