From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 5 Aug 2020 09:14:58 -0400 Subject: [PATCH] Convert CONFIG_SYS_MMC_ENV_DEV et al to Kconfig In-Reply-To: <4D0928EC-7CF2-4017-A870-E3950C42753F@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> Message-ID: <20200805131458.GM6965@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: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. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: