[openwrt/openwrt] ipq806x: chromium: Disable kernel's CONFIG_QCOM_SPM

LEDE Commits lede-commits at lists.infradead.org
Sun Aug 27 13:54:27 PDT 2023


hauke pushed a commit to openwrt/openwrt.git, branch master:
https://git.openwrt.org/9ea5487ea51a2279633410ee7a70168e0253223c

commit 9ea5487ea51a2279633410ee7a70168e0253223c
Author: Brian Norris <computersforpeace at gmail.com>
AuthorDate: Fri Aug 11 17:49:58 2023 -0700

    ipq806x: chromium: Disable kernel's CONFIG_QCOM_SPM
    
    The qcom spm driver is currently broken for IPQ8064 OnHub devices on
    kernel 6.1, such that it hangs the system when booting, much to the
    consternation of users. This is especially bad as these devices don't
    yet have a fully-supported release branch, and are still sometimes
    landing on snapshot builds.
    
    OnHub devices have their own kernel config, so it's not that wide of an
    impact to disable this.
    
    I haven't fully gotten to the bottom of this, but:
    
    (a) The vendor kernel didn't have any SPM driver at all, and didn't
        utilize cpuidle.
    (b) The device tree has never included any (non-disabled) cpuidle
        states, so even when this driver was present on 5.15 (last
        known-working kernel), it didn't actually do anything -- it bailed
        early, before ever doing any SPM initialization.
    (c) Refactoring in Linux 5.16 [1] caused the SPM driver to be activated
        unconditionally, including setting us into standby mode
        (PM_SLEEP_MODE_STBY) by default.
    
    Removing the one PM_SLEEP_MODE_STBY line from drivers/soc/qcom/spm.c
    seems to fix the problem, but that isn't much different than simply
    disabling the driver, so I go with that for now.
    
    I also disable CONFIG_ARM_QCOM_SPM_CPUIDLE, becuase it 'select's
    QCOM_SPM.
    
    NB: it's possible there's some other deeper root cause involved in here.
    For one, I notice that CPU hotplug (e.g., echo 0 >
    /sys/devices/system/cpu/cpu1/online, echo 1 > ...) doesn't work right
    either. Perhaps there's some mismatch on upstream Linux qcom-scm
    behavior and the old boot firmware used for these systems? It wouldn't
    be the first time, as we've had some similar incompatibilities on the
    next generation of these devices, Google WiFi [2].
    
    [1] Commit 60f3692b5f0b ("cpuidle: qcom_spm: Detach state machine from
        main SPM handling")
    [2] [RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
        https://lore.kernel.org/linux-arm-kernel/20200913201608.GA3162100@bDebian/
    
    Signed-off-by: Brian Norris <computersforpeace at gmail.com>
---
 target/linux/ipq806x/chromium/config-default | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ipq806x/chromium/config-default b/target/linux/ipq806x/chromium/config-default
index d7db9f7db3..927aba360f 100644
--- a/target/linux/ipq806x/chromium/config-default
+++ b/target/linux/ipq806x/chromium/config-default
@@ -1,7 +1,9 @@
+# CONFIG_ARM_QCOM_SPM_CPUIDLE is not set
 CONFIG_BLK_DEV_SD=y
 CONFIG_LEDS_LP5523=y
 CONFIG_LEDS_LP55XX_COMMON=y
 CONFIG_PHY_QCOM_IPQ806X_USB=y
+# CONFIG_QCOM_SPM is not set
 CONFIG_SCSI=y
 CONFIG_SCSI_COMMON=y
 CONFIG_SG_POOL=y




More information about the lede-commits mailing list