Hi Urvashi, FYI: substituted for the new mailing list address in my reply; Please check your mailman subscription and any MAINTAINERS file that get_maintainer.pl may be acquiring from
On 10/9/26 14:50, Urvashi Sharma wrote: > common/spl/spl_ufs.c refers to BOOT_DEVICE_UFS, which RISC-V does not > define. Selecting CONFIG_SPL_UFS_SUPPORT therefore breaks the build. > > Add the missing enum value, keeping the arm ordering. > > Signed-off-by: Urvashi Sharma <[email protected]> > Cc: Rick Chen <[email protected]> > Cc: Leo <[email protected]> > Cc: Tom Rini <[email protected]> > --- > arch/riscv/include/asm/spl.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/riscv/include/asm/spl.h b/arch/riscv/include/asm/spl.h > index 9c0bf9755c9..4eb799d2237 100644 > --- a/arch/riscv/include/asm/spl.h > +++ b/arch/riscv/include/asm/spl.h > @@ -27,6 +27,7 @@ enum { > BOOT_DEVICE_XIP, > BOOT_DEVICE_BOOTROM, > BOOT_DEVICE_SMH, > + BOOT_DEVICE_UFS, > BOOT_DEVICE_NONE > }; > Is keeping the same ordering as ARM any correct justification if making a breaking change on RISC-V? Would this be considered an ABI change, since U-Boot SPL might be a different boot phase than U-Boot main app? I don't have an opinion for or against the change. Obviously it resolves a compile-time bug. I am wary of causing unexpected behavior for mix-and-match of mainline u-boot and vendor forks from circa 2020/2022/2024 -era, and if we're anyways doing something to cause unexpected behavior then may as well have some style guide or technical justification and not "do as we've always done it on unrelated architecture (x)". Maybe it will just be "do as we have always done on architecture (x)" eventually but I'd like to hear your thoughts on this because there are in-the-wild uses of the mix-and-match situation and a little more information would make this change easier to discover if it does break some ABI (which is fine in my opinion). -E Shattow
