From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 5 Aug 2020 10:52:37 -0400 Subject: [PATCH] Convert CONFIG_SYS_MMC_ENV_DEV et al to Kconfig In-Reply-To: <7AF803CA-9A38-4A15-9BBB-5A6762A40A18@infradead.org> References: <20200724211447.3137-1-trini@konsulko.com> <174b6654-bbe1-9fee-90a6-83e1bd3207a0@prevas.dk> <863b8bdb-1518-ee95-9eaa-03c0b0ab6d7c@denx.de> <20200805125143.GK6965@bill-the-cat> <4D0928EC-7CF2-4017-A870-E3950C42753F@infradead.org> <20200805131458.GM6965@bill-the-cat> <7AF803CA-9A38-4A15-9BBB-5A6762A40A18@infradead.org> Message-ID: <20200805145237.GO6965@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Aug 05, 2020 at 02:22:35PM +0100, David Woodhouse wrote: > On 5 August 2020 14:14:58 BST, Tom Rini wrote: > >On Wed, Aug 05, 2020 at 02:04:02PM +0100, David Woodhouse wrote: > >> > >> > >> On 5 August 2020 13:51:43 BST, Tom Rini wrote: > >> >On Wed, Aug 05, 2020 at 11:07:15AM +0200, Stefan Roese wrote: > >> >> Hi Rasmus, > >> >> > >> >> On 05.08.20 10:47, Rasmus Villemoes wrote: > >> >> > On 24/07/2020 23.14, Tom Rini wrote: > >> >> > > This converts the following to Kconfig: > >> >> > > CONFIG_SYS_MMC_ENV_DEV > >> >> > > CONFIG_SYS_MMC_ENV_PART > >> >> > > >> >> > Yes, please! That's the only thing preventing us from running a > >> >vanilla > >> >> > upstream U-Boot on a number of our boards where we have the > >> >defconfig > >> >> > out of tree - we currently have a single patch touching a few > >> >config > >> >> > headers. > >> >> > > >> >> > > Cc: Priyanka Jain > >> >> > > Cc: Madalin Bucur > >> >> > > Signed-off-by: Tom Rini > >> >> > > --- > >> >> > > Due to some non-environment usage of the variables, cc'ing a > >few > >> >folks. > >> >> > > >> >> > Yes, and those are the reason I didn't already send a patch. > >> >> > > >> >> > > diff --git a/env/Kconfig b/env/Kconfig > >> >> > > index 38e7fadbb93a..2eb2fe48da3d 100644 > >> >> > > --- a/env/Kconfig > >> >> > > +++ b/env/Kconfig > >> >> > > @@ -567,6 +567,25 @@ config SYS_RELOC_GD_ENV_ADDR > >> >> > > Relocate the early env_addr pointer so we know it is not > >> >inside > >> >> > > the binary. Some systems need this and for the rest, it > >> >doesn't hurt. > >> >> > > +config SYS_MMC_ENV_DEV > >> >> > > + int "mmc device number" > >> >> > > + depends on ENV_IS_IN_MMC || ENV_IS_IN_FAT || > >> >SYS_LS_PPA_FW_IN_MMC || \ > >> >> > > + CMD_MVEBU_BUBT || FMAN_ENET || QE > >> >> > > >> >> > Slight yuck. But I suppose that those (ab)uses of > >> >CONFIG_SYS_MMC_ENV_DEV > >> >> > can grow their own proper config symbols piecemeal and then get > >> >removed > >> >> > from that list, rather than having to wean off all of them > >before > >> >> > SYS_MMC_ENV_* can get converted. > >> >> > > >> >> > Why is ENV_IS_IN_FAT in that list? That has its own > >> >already-existing > >> >> > ENV_FAT_DEVICE_AND_PART. > >> > > >> >ENV_IS_IN_FAT is in the list because with 6731bef6966e ("env/fat.c: > >> >allow loading from a FAT partition on the MMC boot device") we can > >pick > >> >up the device dynamically and hard-code the partition. But that in > >> >turn > >> >means needing a default device. This even gets expanded to cover > >ext4 > >> >here: > >> > >>http://patchwork.ozlabs.org/project/uboot/patch/20200804090547.2175076-2-dwmw2 at infradead.org/ > >> > >> > >> FAT and ext4 don't need to grow their own config symbols because they > >already *have* them. The only reason they're involved here is because > >of the case where they explicitly want to *abdicate* responsibility and > >let platform code determine the device to use, not hard-coded config. > >Like the MT7623 platforms where the preloader tells U-Boot if it was > >actually loaded from the internal eMMC or external SD card. > >> > >> If someone is setting up the ENV_FAT_DEVICE_AND_PART to start with a > >colon and thus abdicate the device part, but then that decision is only > >coming from a hard-coded SYS_MMC_ENV_DEV option, then they're probably > >somewhat confused. > > > >Right, but the default mmc_get_env_dev() you added uses > >CONFIG_SYS_MMC_ENV_DEV. > > Perhaps I could revamp the FAT/ext4 patches so that they don't use the default weak function, and if you use the "get it at runtime" behaviour on any build which doesn't actually have a real platform mmc_get_env_dev() function, the build fails. That would be sane, but might involve a separate explicit config option instead of just "the DEVICE_AND_PART option starts with a colon". That sounds like a good idea, thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: