Hi E, Thanks, and sorry about the old list.
Agree that "same as arm" isn't a correct technical justification. The real one is that BOOT_DEVICE_* is SPL-internal. As I can check, it isn't passed to the next stage in any form (handoff, global_data, bloblist or FDT), so mixing SPL and U-Boot proper builds from different trees can't be affected. Adding UFS before NONE leaves every existing value unchanged; only the terminator moves. If you recommend, I can send a v2 with that reasoning in the commit message and a short comment in asm/spl.h documenting the ordering rule. Thanks, Urvashi On Fri, Oct 9, 2026 at 5:52 PM E Shattow <[email protected]> wrote: > > 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
