Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp3937689pxb; Tue, 7 Sep 2021 10:45:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxh42UeX7Q8+L27/86GZzQBnzQQH/mPkqTCYhRcb13BSeFbShqnQ0m9YEr/3gBRsQ6HaO52 X-Received: by 2002:a17:907:f97:: with SMTP id kb23mr20105039ejc.15.1631036734129; Tue, 07 Sep 2021 10:45:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631036734; cv=none; d=google.com; s=arc-20160816; b=SewW6U0xA7KT8kkSrp/RDtXbPXbb8LJ1G7fPnzB8Ea7AMYlu4BydNeCxATdR6xJV9I CmFOSetDumSDebWn3Hyd8Mf/yJqA2agY/GdwHGiimUaTxOxVrH1oNaprmsNhK4brS7wg QevI5we9b3bnZl/zTvDtx/eYbSIDNslCrto5M7DOhZg0UxCLE5bLTuVfRjEyHIDzu2M1 jo3ehZdCfu6DZ2EhzJhmamr77duKmbKkQBzsAv0PXvj/2aOhTSM1ERbCTLlxXN27u288 EgaejoxV7LT/VRRmlexi72jp732YDfTnKa4BrefsZg5MpWC2vPa5BzZ+uh7Ubt278oW5 jTtw== 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:dkim-signature; bh=fK2thzMc0IJwiqIlBOUizs3B5dZVIVtH40fSvScxog0=; b=T8w6ecNR5JBcw3c943kPsPRdowSF5N8P+FLh3fLVBxNdEgEJID2ZnEfwE3tGDhjwWw o+lHYNNJvGi0x6JCe7PRNTe+ro0yCR+BurXUuDVKeOtMfXwWp4lhLr0TBZrb95ZHbYHk 8mO5EKJWKyWbyPDCcMPNxkHMq5gv3YUuryIg+jK72xdVmDBoO0mfWEv2mgMRcmEIuMvX XlffSrKvN+FozrGI9fs13qcgxrIfTI5EbFwThFkExkgNl9vbmNi6FJUcIO4v/YEtWgCT 1jAQZGUJkK7d9zWZYgISJpPCF05NAh08uguC3SYzyoqsJni42+zb6m4FRxkwyEKykk4A rP6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=xUMRrbNX; 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=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m10si10875622ejb.115.2021.09.07.10.45.10; Tue, 07 Sep 2021 10:45:34 -0700 (PDT) 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; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=xUMRrbNX; 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=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345555AbhIGRDB (ORCPT + 99 others); Tue, 7 Sep 2021 13:03:01 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:51438 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345505AbhIGRC7 (ORCPT ); Tue, 7 Sep 2021 13:02:59 -0400 Received: from lelv0266.itg.ti.com ([10.180.67.225]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id 187H1kj4127603; Tue, 7 Sep 2021 12:01:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1631034106; bh=fK2thzMc0IJwiqIlBOUizs3B5dZVIVtH40fSvScxog0=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=xUMRrbNXMSlysxCp7Ib01wh5+B0wZYT5CUGANV9ZObT1nRkH8P3sxxfhgK5rnjg9q 216EX6i49GM7ZFBxFvg6ExJYZ+oDFaAn6fcptSOVErRoldOLCHULFdV5HdbzDb51Bh qk0wYiTRXAQeg5Vr8LFwoIB6FRbYMcymfZo10w1w= Received: from DFLE102.ent.ti.com (dfle102.ent.ti.com [10.64.6.23]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 187H1k8k019509 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 7 Sep 2021 12:01:46 -0500 Received: from DFLE105.ent.ti.com (10.64.6.26) by DFLE102.ent.ti.com (10.64.6.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Tue, 7 Sep 2021 12:01:46 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE105.ent.ti.com (10.64.6.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Tue, 7 Sep 2021 12:01:45 -0500 Received: from [10.250.232.51] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 187H1gur066531; Tue, 7 Sep 2021 12:01:43 -0500 Subject: Re: [PATCH 1/3] arm64: dts: ti: iot2050: Flip mmc device ordering on Advanced devices To: Nishanth Menon CC: Jan Kiszka , Tero Kristo , Rob Herring , , , , Bao Cheng Su , Chao Zeng References: <8e2e435ef67868cb98382b44c51ddb5c8d045d66.1631024536.git.jan.kiszka@siemens.com> <20210907151301.7fqwmc7hmcyhhybv@carve> <35e0cadf-526c-6402-fb8e-8cdb8b7a0bfe@siemens.com> <20210907152746.fbddtkktvx6hb5ti@cattishly> <20210907153547.53cc2zx23rx72kqf@thyself> <482dddc1-b1f8-15db-a0c5-0d6def5d859f@ti.com> <20210907165316.4s3jrouctcpc3kvo@pessimism> From: Aswath Govindraju Message-ID: Date: Tue, 7 Sep 2021 22:31:42 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210907165316.4s3jrouctcpc3kvo@pessimism> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nishanth, On 07/09/21 10:23 pm, Nishanth Menon wrote: > On 22:17-20210907, Aswath Govindraju wrote: >> Hi Nishanth, >> >> On 07/09/21 9:05 pm, Nishanth Menon wrote: >>> On 17:30-20210907, Jan Kiszka wrote: >>>> On 07.09.21 17:27, Nishanth Menon wrote: >>>>> On 17:20-20210907, Jan Kiszka wrote: >>>>>> On 07.09.21 17:13, Nishanth Menon wrote: >>>>>>> On 16:22-20210907, Jan Kiszka wrote: >>>>>>>> From: Jan Kiszka >>>>>>>> >>>>>>>> This ensures that the SD card will remain mmc0 across Basic and Advanced >>>>>>>> devices, also avoiding surprises for users coming from the downstream >>>>>>>> kernels. >>>>>>>> >>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>> --- >>>>>>>> arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts | 5 +++++ >>>>>>>> 1 file changed, 5 insertions(+) >>>>>>>> >>>>>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts >>>>>>>> index ec9617c13cdb..d1d5278e0b94 100644 >>>>>>>> --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts >>>>>>>> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts >>>>>>>> @@ -18,6 +18,11 @@ / { >>>>>>>> compatible = "siemens,iot2050-advanced", "ti,am654"; >>>>>>>> model = "SIMATIC IOT2050 Advanced"; >>>>>>>> >>>>>>>> + aliases { >>>>>>>> + mmc0 = &sdhci1; >>>>>>>> + mmc1 = &sdhci0; >>>>>>>> + }; >>>>>>> >>>>>>> >>>>>>> Should we do this at SoC level? >>>>>>> >>>>>> >>>>>> Well, I wouldn't mind - but that would also impact your EVMs. For us, >>>>>> this is fine as we are coming from that ordering above with our >>>>>> downstream kernel/dts. >>>>>> >>>>> >>>>> I think it'd probably be a welcome change. overall we've standardized on >>>>> partuuid. >>>>> >>>> >>>> Yeah, it's more about "dd if=emmc.img of=/dev/mmcblk1 - damn, the wrong >>>> one again." >>>> >>>> Let me know what you prefer, and I'll update my patch. >>> >>> >>> Lets do it at SoC level. I will follow it up with a patch for other K3 >>> SoCs as well. >>> >>> >>> Unless someone has a strong opinion on this approach - if so, speak up >>> with reasons. >>> >> >> Making this change in SoC level for all K3 devices would force changes >> to be made in U-Boot too, for consistency. In U-Boot, a major change >> would be required in the environment variables to support this. As I >> don't see any functional advantage by making this change, I feel that >> this change would make things more confusing for users already using the >> K3 devices. At present, the ordering is consistent across all the K3 >> devices, I feel that keeping it the same way would be better. >> >> As for making changes only on IoT boards, if it is okay to have the >> ordering changed between U-Boot and kernel, I don't see any problem >> making this change in kernel alone. > > > arch/arm64/boot/dts/ti/k3-am65.dtsi has no ordering. u-boot is supposed > to copy from kernel the dtsi files as is. I think having mmc aliases in > kernel is a good thing as we do regard kernel as the canonical dts > source. > Yes, you are correct. Aliases are not added for mmc in U-Boot too, but due to the ordering in the device tree, mmc0 is always sdhci0 and mmc1 is always sdhci1 in U-Boot. I agree that, in kernel as the probe order is not guaranteed, fixing the order would be better by adding aliases explicitly. > If you are suggesting we flip things so that mmc0 is sdhci0 and mmc1 is > sdhci1 - that might be a valid suggestion - Jan, do you see a problem > in having consistency here (flip the aliases)? > > Yes, I am suggesting a flip in the order and this order can be applied across all the K3 SoC's Thanks, Aswath