[PULL] Please pull casey/qcom-main-13Apr2026

[Sumit Garg]

On Mon, Apr 27, 2026 at 12:30:22PM +0200, Casey Connolly wrote:
> 
> 
> On 27/04/2026 08:59, Sumit Garg wrote:
> > Hi Casey,
> > 
> > On Sun, Apr 19, 2026 at 09:40:26AM -0600, Tom Rini wrote:
> >> On Sun, Apr 19, 2026 at 05:03:16AM +0200, Casey Connolly wrote:
> >>
> >>> Hi Tom,
> >>>
> >>> Various Qualcomm additions this cycle:
> >>> * USB superspeed support for 1 platform
> >>> * Initial support for the Milos platform and the Fairphone Gen 6 (chainloaded from ABL)
> >>> * Improved support for booting with OP-TEE on supported platforms
> >>> * Initial basic power domain support
> >>>
> >>> Notably there is a generic change to the device core, missing power
> >>> domains will no longer cause a device to fail probe and instead will
> >>> just print a warning. This shouldn't affect any existing platforms.
> >>
> >> Unfortunately I get a fail to build in CI:
> >> https://source.denx.de/u-boot/u-boot/-/jobs/1428016
> >> +(qcm6490) drivers/phy/qcom/phy-qcom-qmp-combo.c: In function 'qmp_combo_com_init':
> >> +(qcm6490) drivers/phy/qcom/phy-qcom-qmp-combo.c:288:35: error: unused variable 'cfg' [-Werro
> >> r=unused-variable]
> >> +(qcm6490)   288 |         const struct qmp_phy_cfg *cfg = qmp->cfg;
> >> +(qcm6490)       |                                   ^~~
> >> +(qcm6490) cc1: all warnings being treated as errors
> >> +(qcm6490) make[4]: *** [scripts/Makefile.build:271: drivers/phy/qcom/phy-qcom-qmp-combo.o] E
> >> rror 1
> >> +(qcm6490) make[3]: *** [scripts/Makefile.build:492: drivers/phy/qcom] Error 2
> >> +(qcm6490) make[2]: *** [scripts/Makefile.build:492: drivers/phy] Error 2
> >> +(qcm6490) make[1]: *** [Makefile:2205: drivers] Error 2
> > 
> > Do you plan to re-send this PR with updated USB super speed patch-set
> > from Balaji here [1] which should take care of this CI issue?
> 
> Tom: I'll fix the issue and send a rebased PR, I thought CI was passing
> but I guess I missed that :/ apologies for not doing this last week I
> was OOO.
> 
> v4 doesn't fix this warning, it also changes the fixup logic to use a
> compatible match, im a bit confused by this change since we discussed
> why that approach was preferable in the first place.
> 
> I'd like to understand how significant is the overhead of the old logic
> to justify this.
> 
> I'm going to keep v3 since that's what I tested and we can discuss
> dropping the logic if the overhead is too much.
> 

The overhead for DT traversal here was ~125ms on RB3Gen2. And it can be
much slower on platforms like RB1, see discussion here [1]. We do have
to care about boot time on all platforms. So it is rather better we keep
the boot time under check and hence v4 logic is better here.

[1] https://lore.kernel.org/all/aU5tx8VkWCxwLbHN@sumit-xelite/

-Sumit