[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <19b62068.1082.193ed25f901.Coremail.andyshrk@163.com>
Date: Sun, 22 Dec 2024 14:55:09 +0800 (CST)
From: "Andy Yan" <andyshrk@....com>
To: Heiko Stübner <heiko@...ech.de>
Cc: dsimic@...jaro.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-rockchip@...ts.infradead.org, krzk+dt@...nel.org,
"Andy Yan" <andy.yan@...k-chips.com>
Subject: Re:Re: [PATCH] arm64: dts: rockchip: aliase sdhci as mmc0 for
rk3566 box demo
Hi Heiko,
At 2024-12-21 20:55:02, "Heiko Stübner" <heiko@...ech.de> wrote:
>Hi Andy,
>
>Am Samstag, 21. Dezember 2024, 11:49:07 CET schrieb Andy Yan:
>> From: Andy Yan <andy.yan@...k-chips.com>
>>
>> Follow most others rk356x based boards, and u-boot only use mmc0/1
>> as mmc boot targets, so aliase sdhci as mmc0.
>>
>> Signed-off-by: Andy Yan <andy.yan@...k-chips.com>
>> ---
>>
>> arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts b/arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts
>> index 41b4cd5a4220..7d0eedf1bd0d 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3566-box-demo.dts
>> @@ -19,9 +19,9 @@ / {
>>
>> aliases {
>> ethernet0 = &gmac1;
>> - mmc0 = &sdmmc0;
>> - mmc1 = &sdmmc1;
>> - mmc2 = &sdhci;
>> + mmc0 = &sdhci;
>> + mmc1 = &sdmmc0;
>> + mmc2 = &sdmmc1;
>
>sorry, but that won't be possible :-( .
>
>The original aliases for the mmc order were added over 2 years ago
>(november 2022) and became part of the ABI then.
Yes, the patch for this board was submitted by me.
This is a tv box evaluation demo board that we use internally,and it is not sold to the public.
I submitted it to the mainline because it is small, compact and streamlined, it easy for me
to use it test the mainline vop2 driver.
I think i am currently the only user who will use this board run the mainline kernel.
I'm not sure if we can let it go.
>
>Imagine someone using that board with a rootfs=/dev/mmcblk2p1 part
>in the commandline to mount the old sdhci-part1 as rootfs, but now
>you reorder the controllers, so so that commandline would try to access
>sdmmc1, so their system won't boot anymore after just a simple kernel
>update.
>
>Breaking people's setup is one of those big no-go-s in the kernel, so
>sadly you'll need to live with the existing order.
>
>
>Heiko
>
>
Powered by blists - more mailing lists