[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5e0b908b-52c8-494e-a804-393c8aad097a@wolfvision.net>
Date: Wed, 8 Jun 2022 15:08:41 +0200
From: Michael Riesch <michael.riesch@...fvision.net>
To: Heiko Stübner <heiko@...ech.de>,
linux-rockchip@...ts.infradead.org,
Sjoerd Simons <sjoerd@...labora.com>
Cc: kernel@...labora.com, Akash Gajjar <akash@...nedev.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: rock-pi-s add more peripherals
Hi all,
On 6/8/22 14:19, Heiko Stübner wrote:
> Am Mittwoch, 8. Juni 2022, 14:07:33 CEST schrieb Sjoerd Simons:
>> Hey Michael,
>>
>> On Mon, 2022-06-06 at 14:00 +0200, Michael Riesch wrote:
>>>
>>>> + aliases {
>>>> + ethernet0 = &gmac;
>>>> + mmc0 = &emmc;
>>>> + mmc1 = &sdmmc;
>>>
>>> Sure? emmc is at address ff49000 which is larger than sdmmc's address
>>> ff480000. I believe the aliases should be sorted w.r.t. addresses.
>>
>> Do you have a reference about this sorting requirement?
No, not really. I did have the impression that such a convention existed...
> I do believe we used that mmcx -> *mmc-device sorted by address
> when the aliases still were in the main soc dtsi. Simply because one
> couldn't really know what was available on a specific board
> (no emmc for example).
... and this seems to be the case indeed...
> I guess now on a per-board level we could actually do that more relaxed
> and let that be the decision of the board submitter ;-) .
... but apparently the convention is not that crucial anymore :-) Just
wanted to point it out.
>> Also do you mean that mmc0 should be &sdmmc *or* that the aliases
>> should have mmc1 listed first.
FTR, I would have suggested
mmc0 = &sdmmc;
mmc1 = &emmc;
according to said convention, but then I would also take a look on
whatever any other rk3308 boards do and aim to be in sync...
>> For reference the reason is that mmc0 is emmc is because it seems more
>> logical to have the builtin devices come first (e.g. as mmcblk0)
... unless there is a good reason not to. You be the judge of that ;-)
Best regards,
Michael
>> [...]
Powered by blists - more mailing lists