[PATCH v8 07/12] mach-snapdragon: Kconfig: changes / additions to support SPL

[Tom Rini]

On Wed, May 20, 2026 at 12:13:04AM +0200, Michael Srba wrote:
> Hi,
> 
> On 5/19/26 19:22, Tom Rini wrote:
> > On Sat, May 16, 2026 at 08:19:56PM +0200, michael.srba at seznam.cz wrote:
> > 
> > > From: Michael Srba <Michael.Srba at seznam.cz>
> > > 
> > > Select SUPPORT_SPL so SPL build can be enabled, disable SYSRESET_PSCI in SPL.
> > > (SPL runs in EL3, so if SPL itself doesn't provide PSCI, nothing else will.)
> > > 
> > > Also select (SPL_)OF_LIVE and DM_EVENT/SPL_EVENT, which are needed to fix up
> > > upstream dt to make usb work.
> > > 
> > > Mirror u-boot proper selections like GPIO and pinctrl to ensure consistent
> > > behavior, and select SPL_SPRINTF, SPL_LIBCOMMON_SUPPORT etc for similar
> > > reasons.
> > > 
> > > Signed-off-by: Michael Srba <Michael.Srba at seznam.cz>
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > ---
> > >   arch/arm/Kconfig                 | 33 ++++++++++++++++++++++++++++++++-
> > >   arch/arm/mach-snapdragon/Kconfig | 10 ++++++++++
> > >   2 files changed, 42 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 850768282ce..255d2035cdc 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -1136,6 +1136,7 @@ config ARCH_SNAPDRAGON
> > >   	bool "Qualcomm Snapdragon SoCs"
> > >   	select ARM64
> > >   	select DM
> > > +	select DM_EVENT if USB_DWC3_GENERIC
> > >   	select DM_GPIO
> > >   	select DM_SERIAL
> > >   	select DM_RESET
> > After looking in to what's going on here more, this should be:
> > 	select EVENT if OF_LIVE
> > 
> > And is a standalone bug fix. The event in question here lives in
> > arch/arm/mach-snapdragon/of_fixup.c and is for both USB things and
> > OP-TEE things
> That's probably new stuff since I looked at it

Possibly. This should have come in with commit 5a1dfb27f917
("mach-snapdragon: use EVT_OF_LIVE_INIT to apply DT fixups").

> >   (so USB_DWC3_GENERIC is wrong), but desired even if U-Boot
> > doesn't use USB as the linux kernel will consume this device tree, if I
> > recall correctly.
> I think the USB fixup is explicitly not supposed to be passed to Linux,
> since it's just a workaround for the driver not falling back to usb 2.0
> only operation (and some issue with usb3 operation, don't recall
> the exact details). IIRC the code works on a copy or something
> of the sort.
> Not sure if the op-tee things are supposed to be passed to Linux
> or not though.

I could be mistaken in the run-time usage part. But I've been kicking
the rest of this event stuff around now for most of the day and I'm
quite sure on when we should have been adding "select EVENT".

> >   But next, this only fires on EVT_OF_LIVE_BUILT and not
> > one of EVT_DM_POST_INIT_[FR] which is what DM_EVENT gates.
> > 
> > All of that said, what exactly is the failure to build you saw in your
> > series, without the above? I do worry there's something else further
> > going on here. Thanks!
> > 
> Hm, EVT_OF_LIVE_BUILT definitely needed SPL_EVENT to work in SPL, maybe I accidentally added DM_EVENT when I was debugging that and then later I assumed I added it on purpose? I don't think it was a compilation failure, since even SPL_EVENT not existing didn't cause that, it just caused lack of working usb.

OK, yeah. I too got confused for a bit on DM_EVENT vs EVENT.

> Maybe I intended to `select EVENT` instead... and DM_EVENT selects that transitively, so I may have originally selected that in menuconfig thinking "I'll do it properly later"... I really should remember why and what I did, but oh well, hope my educated guesses are of use. I hope you didn't waste much time on this since I really feel like it should've been `select EVENT`, especially in retrospect, and again I don't think it was a build failure, just the fixup callback didn't get executed (fwiw I only tested in SPL, and I assume it does get executed in u-boot proper at least in the cases where it was tested by others, but without `select EVENT` I'm not sure how)

I'm glad you found this really, it's caused me to find and fix two
direct bugs (this one, and the TDX_CFG_BLOCK option also needing to
select EVENT) and make it clearer when this would fail to build for the
future. It's also gotten me looking at some other linker list issue I've
needed to.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260519/2205e38e/attachment.sig>