On Fri, Jan 09, 2026 at 02:21:28PM +0530, Balaji Selvanathan wrote: > Hi Simon, > > On 1/8/2026 11:12 PM, Simon Glass wrote: > > Hi Balaji, > > > > On Wed, 7 Jan 2026 at 23:50, Balaji Selvanathan > > <[email protected]> wrote: > > > Add support for locating SCSI environment partition using GPT type > > > GUID instead of unique UUID. This enables the saveenv command to > > > work with partitions identified by their type rather than unique > > > identifiers, providing flexibility for systems where partition > > > UUIDs may vary across devices but types remain constant. > > > > > > Introduce CONFIG_SCSI_ENV_PART_TYPE_GUID configuration option that > > > allows specifying a partition type GUID for environment storage. > > > When enabled, the environment subsystem uses the new type GUID > > > based lookup method via scsi_get_blk_by_type_guid() to find the > > > first matching partition. > > > > > > This change maintains backward compatibility with the existing > > > UUID-based approach. > > > > > > Signed-off-by: Balaji Selvanathan <[email protected]> > > > --- > > > env/Kconfig | 7 +++++++ > > > env/scsi.c | 13 +++++++++++++ > > > 2 files changed, 20 insertions(+) > > > > > > diff --git a/env/Kconfig b/env/Kconfig > > > index b312f9b5324..97cb3d05daf 100644 > > > --- a/env/Kconfig > > > +++ b/env/Kconfig > > > @@ -768,6 +768,13 @@ config SCSI_ENV_PART_UUID > > > help > > > UUID of the SCSI partition that you want to store the > > > environment in. > > > > > > +config SCSI_ENV_PART_TYPE_GUID > > > + string "SCSI partition type GUID for saving environment" > > > + depends on ENV_IS_IN_SCSI > > > + help > > > + Type GUID of the SCSI partition to store the environment in. > > > + Uses the first partition matching this type GUID. > > > + > > > config ENV_USE_DEFAULT_ENV_TEXT_FILE > > > bool "Create default environment from file" > > > depends on !COMPILE_TEST > > > diff --git a/env/scsi.c b/env/scsi.c > > > index 207717e17b1..6182ae26679 100644 > > > --- a/env/scsi.c > > > +++ b/env/scsi.c > > > @@ -35,8 +35,13 @@ static inline struct env_scsi_info > > > *env_scsi_get_part(void) > > > { > > > struct env_scsi_info *ep = &env_part; > > > > > > +#ifdef CONFIG_SCSI_ENV_PART_TYPE_GUID > > > + if (scsi_get_blk_by_type_guid(CONFIG_SCSI_ENV_PART_TYPE_GUID, > > > &ep->blk, &ep->part)) > > Can you use if IS_ENABLED(CONFIG_SCSI_ENV_PART_TYPE_GUID) > > > > (we try to avoid #ifdef) > Thanks for the feedback. > > In this respin > https://lore.kernel.org/u-boot/[email protected]/, > I've introduced a choice statement in env/Kconfig to ensure mutual > exclusivity between CONFIG_SCSI_ENV_PART_UUID and > CONFIG_SCSI_ENV_PART_TYPE_GUID. > > Due to this choice-based configuration, only one of these string configs is > defined at compile time. When I attempted to use `if (IS_ENABLED(...))` for > the string concatenation cases, I encountered compilation errors because the > compiler tries to evaluate both branches, but the undefined config macro > causes an "undeclared identifier" error. > > For example: > > if (IS_ENABLED(CONFIG_SCSI_ENV_PART_USE_TYPE_GUID)) > env_set_default(CONFIG_SCSI_ENV_PART_TYPE_GUID " partition not found", > 0); > else > env_set_default(CONFIG_SCSI_ENV_PART_UUID " partition not found", 0); > // Error: CONFIG_SCSI_ENV_PART_UUID undeclared > > Given this constraint with mutually exclusive string configs, I've kept the > #ifdef approach for these specific cases. I understand the preference for > IS_ENABLED() for its compile-time checking benefits, but in this scenario > with string concatenation, the preprocessor conditional appears to be > necessary. > > Would this approach be acceptable, or would you prefer an alternative > solution?
The way to solve this would be to wrap CONFIG_SCSI_ENV_PART_*UID with CONFIG_VAL(...), but at that point we've also lost the readability argument of avoiding #ifdef. -- Tom
signature.asc
Description: PGP signature
