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

[Casey Connolly]

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.

> 
> Since the v2026.04-rc1 is going to be tagged today, we really don't want
> to miss this merge window again for all these pending features to be
> merged.

I appreciate that, you've been more than clear about your feelings on
this and I hope I've been clear enough about addressing it.

Kind regards,

> 
> [1] https://lore.kernel.org/all/20260418-kodiak_ss-v4-0-d381670c9d78@oss.qualcomm.com/
> 
> -Sumit

-- 
// Casey (she/her)