Arduino UnoQ (qrb2210-arduino-imola) boot regression on qcom-next

[obbardc]

Arduino Uno Q (Agatti; qrb2210-arduino-imola) fails to boot with qcom-next for many weeks with a repeating kernel error:

[   37.053199] CPUidle PSCI: failed to create CPU PM domains ret=-517
[   37.062307] CPUidle PSCI: failed to create CPU PM domains ret=-517
[   37.071053] CPUidle PSCI: failed to create CPU PM domains ret=-517
[   37.080153] CPUidle PSCI: failed to create CPU PM domains ret=-517

I've tracked the regression down to the series Register MPM under CPU cluster power domain to manage RPM notification which was part-merged into qcom-next (through the early/hwe/shikra/drivers branch)

The root-cause for the regression on qrb2210-arduino-imola is that the Agatti DTS changes were never merged. The series splits one change across two halves that must land together:

• Patch 2 removes pm_genpd_init() and of_genpd_add_provider_simple() from the mpm driver so nothing registers a genpd provider for the mpm node anymore.
• Patch 6 removes the DT references to that provider.

qcom-next has patch 2 merged but not patch 6, so agatti.dtsi still has cluster_pd { power-domains = <&mpm>; } which points to a parent domain that nothing provides genpd remapped it to -EPROBE_DEFER and since no driver would ever register that provider, it retried forever. Hence -517 repeating in the log.

Patch 6 was submitted, but was closed by stale bot: qualcomm-linux/kernel-topics#1548

It surfaced on imola alone because imola has zero DT overrides and inherits agatti.dtsi. RB1 escapes it by deleting cluster_pd outright (3da0a5d911cc, 2024) and shikra escapes because its idle states were reverted in this tree. imola was the only board actually exercising the path.

I think we should revert all of these commits.

See-also:

• Register MPM under CPU cluster power domain #832
• UART Shell hung on shikra board with 7.2-rc5 #921
• FROMLIST: arm64: dts: qcom: qcm2290: Do not mark MPM as power domain kernel-topics#1548

cc smankad-oss