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

[Michael Srba]

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
>   (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.
>   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.
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)