Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1257250pxb; Wed, 4 Nov 2020 04:20:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJzTVmyhXk8tamC3JuCUniAnwmwoLHHcJXwJ+fnAQl0elMILXA/avxJ5iNN3taXEKXrpvflS X-Received: by 2002:a17:906:1317:: with SMTP id w23mr17753490ejb.120.1604492432322; Wed, 04 Nov 2020 04:20:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604492432; cv=none; d=google.com; s=arc-20160816; b=cu5ImILsF7/A9eNHcdD/pskXbNXI+sw0V6e/WPVRPFFoTzWTX5jgVHGGanwPTpkBMU /SUlJE2ToOFYbeRkdIg8SMv4mWru/QYyidaMJESS3ZwaI2zRvO3zZQkZ1eYaZgDXV+ws rSH+pml9nuqEoercKzUqGDienM3qZ3d5bHxou0AZRNn7fR54XnN85q5juibfkchu44Bu rGW7sZLpcV8ltvMIIKoYpmEhwTSEITfWGhzgMHPRojpWUWVVfyOzone9V3yaxUAidzug 7vX7gPRXrFXMO2BrOtdz71yKB+zCY5/g50L/4PAdlffVwRNeqSQ/YM7EvvktuChqRUYU 5cLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=brxy6NS1tllb2qonCNEjLs8geqpI8u9nwBfAAPtMmAc=; b=ozAYQgd9yaVUZi6tH0j93vaIJMGGzMPT3JgP2sZ/WsA5GmFusTOxLjV9Q8Xu27um9q oM26x95mHS8dewfPP2VO82/z3bVDY5CCcVMxsk87jIPD6mg8Pdt0W7xuzmdXXJFXIHXO 48DXIOu0ehNJTSRJQHcGhiuBSXzycv/LJdGRowY6EsdxW0zcnAmTM2lu5q2KXHmtdI5H SEke8Fdo4InyJcrRYIWL4SDakOsDcXOEdc7K7elUC59fiblkGzEQphoA6lNjPcxfHAtf +2yaLdvdiLpR2qmLfr6k4+o703wh+RQ9IkLH2m6MkeX85yRKA55f9nOdDMXq6SDVLGKg pirw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 63si1129248edb.454.2020.11.04.04.20.09; Wed, 04 Nov 2020 04:20:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729842AbgKDMSA (ORCPT + 99 others); Wed, 4 Nov 2020 07:18:00 -0500 Received: from foss.arm.com ([217.140.110.172]:36108 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729735AbgKDMSA (ORCPT ); Wed, 4 Nov 2020 07:18:00 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 87CF61474; Wed, 4 Nov 2020 04:17:59 -0800 (PST) Received: from [10.57.54.223] (unknown [10.57.54.223]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DE70B3F719; Wed, 4 Nov 2020 04:17:57 -0800 (PST) Subject: Re: [PATCH] arm64: dts: rockchip: Assign a fixed index to mmc devices on rk3399-roc-pc boards. To: Markus Reichl , =?UTF-8?Q?Heiko_St=c3=bcbner?= , linux-rockchip@lists.infradead.org, Liam Girdwood , Mark Brown , Rob Herring Cc: Rob Herring , dianders@chromium.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org References: <20201104094950.2096-1-m.reichl@fivetechno.de> <4984701.vSXMUKeAfh@diego> <4f4a83f2-3c9b-9549-0acf-057257b4255d@fivetechno.de> From: Robin Murphy Message-ID: Date: Wed, 4 Nov 2020 12:17:57 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <4f4a83f2-3c9b-9549-0acf-057257b4255d@fivetechno.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-11-04 11:15, Markus Reichl wrote: > Hi Heiko, > > Am 04.11.20 um 11:51 schrieb Heiko Stübner: >> Hi Markus, >> >> Am Mittwoch, 4. November 2020, 10:49:45 CET schrieb Markus Reichl: >>> Recently introduced async probe on mmc devices can shuffle block IDs. >>> Pin them to fixed values to ease booting in evironments where UUIDs >>> are not practical. Use newly introduced aliases for mmcblk devices >>> from [1]. >>> >>> [1] >>> https://patchwork.kernel.org/patch/11747669/ >>> >>> Signed-off-by: Markus Reichl >>> --- >>>  arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi | 5 +++++ >>>  1 file changed, 5 insertions(+) >>> >>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi >>> b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi >>> index e7a459fa4322..bc9482b59428 100644 >>> --- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi >>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi >>> @@ -13,6 +13,11 @@ / { >>>      model = "Firefly ROC-RK3399-PC Board"; >>>      compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399"; >>> >>> +    aliases { >>> +        mmc0 = &sdmmc; >>> +        mmc1 = &sdhci; >>> +    }; >>> + >> >> Any reason for this odering? > > Without pinning roc-pc mostly booted as > mmcblk0 = sdmmc = µSD > mmcblk1 = sdhci = eMMC > so I kept this behaviour in aliases > > roc-pc-mezzanine with populated SDIO-M2-slot booted > mmc0 = sdio = (no mmcblk) > mmcblk1 = sdmmc = µSD > mmcblk2 = sdhci = eMMC FWIW that's also how my NanoPC-T4 behaves. Given that it's the order they appear in the DT, not too surprising ;) Robin. > With my aliases both boards behave the same now and the optional SDIO slot > goes out of the way to mmc2. > >> >> I.e. some previous incarnations had it ordered as (emmc, mmc, sdio). >> This is also true for the ChromeOS out-of-tree usage of those, the >> rk3399 dts in the chromeos-4.4 tree also orders this as sdhci, sdmmc, >> sdio. > > The boards from my zoo (exynos, rk3399) mostly come up with SD-card as mmc0 > and eMMC as mmc1 in mainline as opposed in some vendor kernels. > but I have no objection to set it the other way round if this is more > common > with rk3399 boards. > >> >> And I guess a further question would be when we're doing arbitary >> orderings >> anyway, why is this not in rk3399.dtsi ;-) ? > > I restricted the ordering to the boards I have, not to confuse other > established > use cases, but if a standard ordering is desired this can go to > rk3399.dtsi. > >> >> >> Heiko >> >> > > Gruß,