From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A38971 for ; Fri, 30 Apr 2021 09:10:39 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 875515C0032; Fri, 30 Apr 2021 05:10:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 30 Apr 2021 05:10:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=DgPXkCNwhuM1PvuNpQB5vO85GXk 9IVTLv4pIOEkACM8=; b=v3lFalLS2TrtaF/aAKRNtCRKo3X9KKsTJPpbZDbALtO TBZfUyMeRdDSnVkzhYJ0hTaRqiK1la++4dg3x/o/lFAZJjWKEjouSxHiXjpp/7V3 GcZtuH7Jz0vb+aK9kQO1NpHjdSqA5NXZLm98uz0dE+LLfiWsso+BoBulMdGJ/BCg NLCkTemN9sdyyOjFIoYRBoi6CmjhlsZtIEreEnIiXVY1XbP512vkemu76JtmQG+T soYufUFwf6paOCwAS1zu4aYfjUlf9YzruiIRIHy/If8w/vi2uH6E7PsDslYx2T5v 3dtGpNGWPDK9N/b2IdfhOtXKPuoPtRKbRukx/PplrCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DgPXkC NwhuM1PvuNpQB5vO85GXk9IVTLv4pIOEkACM8=; b=sFY/ECTsNNXUjSfwBt6lFu BJfDhttISlFO4bU/nzfmphsiTRMvkRfPRdPP3Sdy7C557AhTifO5usvA7iVzrPLM PPbR9noGUEONxwEuDcYz4ok5Nv30zc5qOZ1xsdmqn5H5dzBHHZSSMupZrqZ/EI+h WOwfJ/agiVqE4OYuviOXyC5Sc9/x8NvvZvG4uPV2ompJWuIW8s767yW0+NRj+lrD wm2W/SQ9YVQAoF7jfGN9bf+ORVQ+hE3IZRw79eCSw9Jebt31hDV5XQ2bTYaEiB8b GMyxricEnXr5+kmywZ7x/VpkKnJLij8chr3yWx10Ol+dvSTGsHCpUO1Ai8AvC74Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddviedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 30 Apr 2021 05:10:37 -0400 (EDT) Date: Fri, 30 Apr 2021 11:10:35 +0200 From: Maxime Ripard To: Andre Przywara Cc: Chen-Yu Tsai , Samuel Holland , Jernej Skrabec , devicetree , linux-arm-kernel , linux-sunxi@lists.linux.dev, linux-kernel Subject: Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering Message-ID: <20210430091035.i4zoyzb4c2l22msb@gilmour> References: <20210419025246.21722-1-samuel@sholland.org> <20210419095443.1548432e@slackpad.fritz.box> X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5enpgdo5lledv3vf" Content-Disposition: inline In-Reply-To: <20210419095443.1548432e@slackpad.fritz.box> --5enpgdo5lledv3vf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2021 at 09:54:43AM +0100, Andre Przywara wrote: > On Mon, 19 Apr 2021 11:17:19 +0800 > Chen-Yu Tsai wrote: >=20 > Hi, >=20 > > On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland w= rote: > > > > > > Dealing with the inconsistent numbering has been a major pain, and > > > there is a solution with (as far as I can tell) no tangible downsides. > > > So let's use it. >=20 > Thanks Samuel for sending this! >=20 > > > Yes, I know the kernel supports UUIDs for root=3D. But UUIDs do not h= elp > > > when referencing the whole, unpartitioned device, like is needed for > > > updating the bootloader and firmware. So for the use case of "write a > > > bootloader to the SD card, regardless of where the board is currently > > > booted from", I know of two options: > > > - Dig around in sysfs to find the mmc number from the MMIO address, > > > which means I have to know the MMIO addresses for every SoC, or > > > - Apply patches like these. > > > > > > Samuel Holland (2): > > > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > > > arm64: dts: allwinner: Enforce consistent MMC numbering > > > > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++ > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++ > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++++++ =20 > >=20 > > At least with Rockchip this is now done at the board level. IIRC it was > > a request from other people to not do it at the SoC level. I don't reca= ll > > exactly who though. >=20 > FWIW, I am very much in favour of these patches, at a SoC level: > The *SoC* BootROM imposes an order, by probing the first (by MMIO > address order) MMC controller first for boot devices. IIRC that's a > different story for Rockchip? > And if people really don't care about the order, then having a certain > order doesn't hurt, so we could as well use the "natural" order, as it > was before. This doesn't have anything to do with the BootRom though but what we provide to the userspace? The userspace has no guarantee about the kernel enumeration order for any bus (but UART for some reason), I'm not really sure why MMC would be an exception. Especially since the kernel will not try to catch up, this will be bound to be broken on a regular basis. And that aside, assuming that a device only has an eMMC this would create the mmc2 device, which is completely weird and inconsistent with how any other bus behaves. > Also UUIDs only help if you boot with an initramfs to resolve them, > which proves to be extra pain if you don't compile kernels on the > device, or not inside a distribution environment. I'm not sure what you mean? The kernel is perfectly able to resolve them. You can also use PARTLABEL if you want something more user friendly. Maxime --5enpgdo5lledv3vf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYIvJiwAKCRDj7w1vZxhR xezdAQDIY6qe0cw/YeAwFhjlA5dAKEDjlxwmNTpj6ztkqfs/4wD/ckzHAVsRq/tR KkQbbJcdqKeAzIEY1dSy+rvOusXqqAA= =DXm6 -----END PGP SIGNATURE----- --5enpgdo5lledv3vf-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72E64C433ED for ; Fri, 30 Apr 2021 09:12:21 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9BC33613D9 for ; Fri, 30 Apr 2021 09:12:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BC33613D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oD8SyaZJnkMIGXeMA6mYDLqkyj2pBx5/vVhaAC3cQl4=; b=lhRPoPqYSQezO9gyxts0RhVKC iQvBzvOCi6LU/7MBLabjZ5gCLx4w6i60VEma3HietxZU8DiLMVzHPJYVNT5P3L2hdhKl9j64Yh87I hnuq+F92t/mJ8qBHW6dzXO2okqkwom5yNx4HzfDrTlcMfXc0EeujngJzMxPyjfpC5uyWDgm1Z6fdw dbB/QgWzEaCFL82NUwmwiyym6Tou6VkSfjqg5bvdbKFMQtifetMLIHN8+uP32qWc7otGjVPRDn47s KHHofSqRhOz25iCPPgI/e9TFGCsUnFw1fQ6ADvquJcQ05F7/nzxybCYugwor46BPNbjLf5cyRf3kh G37WA0BnQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lcPAa-007aK3-Vq; Fri, 30 Apr 2021 09:10:45 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lcPAY-007aJs-6b for linux-arm-kernel@desiato.infradead.org; Fri, 30 Apr 2021 09:10:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=DgPXkCNwhuM1PvuNpQB5vO85GXk9IVTLv4pIOEkACM8=; b=oCKReuzkMk1/c8o6/dyDb+uSg1 mcx9RVzO+x+XGn8lvSgS6n8S+vXoqNosBKf53q1nEi/6TJOa+yQm7P+R3SfcW/AA0qstdXJ0SVuhn q1JQNnS8DZkdyIo3aDQjGVOu0W847df9n7AvgYTjL+pnsl1UX44YzJBm0j/ADVStEvAR/MC0OAdGr /wB7p0rMED7d1T/D3E3jgd+s0Gn5qkmkgy1qyLimsNbXuZpr9Qdi1UAh9+DmPnrEqd2jqhr+MGLGo 2oNGwVzFvu+Tu9UC16WsqY7Ipgj/nKau3Wm9A0WmpVqkIdYer28LCvjsFQIcZYw7SG7D4klb3aPcp X506mcpQ==; Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lcPAV-001GRq-Dv for linux-arm-kernel@lists.infradead.org; Fri, 30 Apr 2021 09:10:40 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 875515C0032; Fri, 30 Apr 2021 05:10:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 30 Apr 2021 05:10:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=DgPXkCNwhuM1PvuNpQB5vO85GXk 9IVTLv4pIOEkACM8=; b=v3lFalLS2TrtaF/aAKRNtCRKo3X9KKsTJPpbZDbALtO TBZfUyMeRdDSnVkzhYJ0hTaRqiK1la++4dg3x/o/lFAZJjWKEjouSxHiXjpp/7V3 GcZtuH7Jz0vb+aK9kQO1NpHjdSqA5NXZLm98uz0dE+LLfiWsso+BoBulMdGJ/BCg NLCkTemN9sdyyOjFIoYRBoi6CmjhlsZtIEreEnIiXVY1XbP512vkemu76JtmQG+T soYufUFwf6paOCwAS1zu4aYfjUlf9YzruiIRIHy/If8w/vi2uH6E7PsDslYx2T5v 3dtGpNGWPDK9N/b2IdfhOtXKPuoPtRKbRukx/PplrCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DgPXkC NwhuM1PvuNpQB5vO85GXk9IVTLv4pIOEkACM8=; b=sFY/ECTsNNXUjSfwBt6lFu BJfDhttISlFO4bU/nzfmphsiTRMvkRfPRdPP3Sdy7C557AhTifO5usvA7iVzrPLM PPbR9noGUEONxwEuDcYz4ok5Nv30zc5qOZ1xsdmqn5H5dzBHHZSSMupZrqZ/EI+h WOwfJ/agiVqE4OYuviOXyC5Sc9/x8NvvZvG4uPV2ompJWuIW8s767yW0+NRj+lrD wm2W/SQ9YVQAoF7jfGN9bf+ORVQ+hE3IZRw79eCSw9Jebt31hDV5XQ2bTYaEiB8b GMyxricEnXr5+kmywZ7x/VpkKnJLij8chr3yWx10Ol+dvSTGsHCpUO1Ai8AvC74Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddviedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepleekgeehhfdutdeljefgleejffehfffgieejhffgueefhfdtveetgeehieeh gedunecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 30 Apr 2021 05:10:37 -0400 (EDT) Date: Fri, 30 Apr 2021 11:10:35 +0200 From: Maxime Ripard To: Andre Przywara Cc: Chen-Yu Tsai , Samuel Holland , Jernej Skrabec , devicetree , linux-arm-kernel , linux-sunxi@lists.linux.dev, linux-kernel Subject: Re: [PATCH 0/2] sunxi: Enforce consistent MMC numbering Message-ID: <20210430091035.i4zoyzb4c2l22msb@gilmour> References: <20210419025246.21722-1-samuel@sholland.org> <20210419095443.1548432e@slackpad.fritz.box> MIME-Version: 1.0 In-Reply-To: <20210419095443.1548432e@slackpad.fritz.box> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210430_021039_569267_A9E1C5DF X-CRM114-Status: GOOD ( 32.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7606413312217729130==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7606413312217729130== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5enpgdo5lledv3vf" Content-Disposition: inline --5enpgdo5lledv3vf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 19, 2021 at 09:54:43AM +0100, Andre Przywara wrote: > On Mon, 19 Apr 2021 11:17:19 +0800 > Chen-Yu Tsai wrote: >=20 > Hi, >=20 > > On Mon, Apr 19, 2021 at 10:52 AM Samuel Holland w= rote: > > > > > > Dealing with the inconsistent numbering has been a major pain, and > > > there is a solution with (as far as I can tell) no tangible downsides. > > > So let's use it. >=20 > Thanks Samuel for sending this! >=20 > > > Yes, I know the kernel supports UUIDs for root=3D. But UUIDs do not h= elp > > > when referencing the whole, unpartitioned device, like is needed for > > > updating the bootloader and firmware. So for the use case of "write a > > > bootloader to the SD card, regardless of where the board is currently > > > booted from", I know of two options: > > > - Dig around in sysfs to find the mmc number from the MMIO address, > > > which means I have to know the MMIO addresses for every SoC, or > > > - Apply patches like these. > > > > > > Samuel Holland (2): > > > ARM: dts: sunxi: h3/h5: Enforce consistent MMC numbering > > > arm64: dts: allwinner: Enforce consistent MMC numbering > > > > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 6 ++++++ > > > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 6 ++++++ > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 6 ++++++ =20 > >=20 > > At least with Rockchip this is now done at the board level. IIRC it was > > a request from other people to not do it at the SoC level. I don't reca= ll > > exactly who though. >=20 > FWIW, I am very much in favour of these patches, at a SoC level: > The *SoC* BootROM imposes an order, by probing the first (by MMIO > address order) MMC controller first for boot devices. IIRC that's a > different story for Rockchip? > And if people really don't care about the order, then having a certain > order doesn't hurt, so we could as well use the "natural" order, as it > was before. This doesn't have anything to do with the BootRom though but what we provide to the userspace? The userspace has no guarantee about the kernel enumeration order for any bus (but UART for some reason), I'm not really sure why MMC would be an exception. Especially since the kernel will not try to catch up, this will be bound to be broken on a regular basis. And that aside, assuming that a device only has an eMMC this would create the mmc2 device, which is completely weird and inconsistent with how any other bus behaves. > Also UUIDs only help if you boot with an initramfs to resolve them, > which proves to be extra pain if you don't compile kernels on the > device, or not inside a distribution environment. I'm not sure what you mean? The kernel is perfectly able to resolve them. You can also use PARTLABEL if you want something more user friendly. Maxime --5enpgdo5lledv3vf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYIvJiwAKCRDj7w1vZxhR xezdAQDIY6qe0cw/YeAwFhjlA5dAKEDjlxwmNTpj6ztkqfs/4wD/ckzHAVsRq/tR KkQbbJcdqKeAzIEY1dSy+rvOusXqqAA= =DXm6 -----END PGP SIGNATURE----- --5enpgdo5lledv3vf-- --===============7606413312217729130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7606413312217729130==--