[RFC] qcom_scm: IPQ4019 firmware does not support atomic API?

Brian Norris computersforpeace at gmail.com
Sun Sep 13 16:16:08 EDT 2020


[ TL;DR: I have an IPQ4019 firmware that needs to effectively revert
commit 13e77747800e ("firmware: qcom: scm: Use atomic SCM for cold
boot"). Am I insane, or is this something that upstream can support
(pending a patch, of course)? ]

Hi Qualcomm maintainers,

I'm bringing up mainline support for an IPQ4019-based system (the
original Google WiFi, if anyone cares), and I'm trying to avoid having
to update its bootloader too -- frankly, I'm not even sure I can effect
any meaningful change on its "secure world" firmware.

Currently, I'm finding that SMP doesn't work, because
qcom_scm_set_cold_boot_addr() returns -4 (QCOM_SCM_EOPNOTSUPP?). If I
switch back to the non-atomic SMC variant (and hack up scm_legacy_call()
a lot, to avoid the DMA API), things work beautifully. Similarly, the
vendor/BSP kernel only uses the non-atomic API for this function. This
suggests to me that my firmware does not support the atomic variant at
all (I see no other such calls being made, besides SMP initialization).

IOW, my current patch looks to effectively revert 13e77747800e
("firmware: qcom: scm: Use atomic SCM for cold boot"), and bring back
ARM32-specific portions of commit 16e59467a446 ("firmware: qcom: scm:
Convert to streaming DMA APIS"). The latter is necessary because the DMA
API is not available to early SMP init, when there is no "device"
available.

I would just post a patch, but:
(a) this looks to be totally opposite of the direction that ARM support
    is "supposed" to be moving and
(b) I've tried that before, for a similar problem domain [1], and was
    met with deafening silence. Considering this patch would be much
    more invasive, I thought I'd just pose a question first instead.

So, back to the TL;DR, am I insane? Well, I may be insane regardless,
but is it reasonable to bring back non-atomic support for this case? I
can try to limit the damage to ARM32 at least (that's the only user of
qcom_scm_set_cold_boot_addr()), but it still isn't the prettiest, given
the "unified" nature of the current qcom_scm driver.

Note that I can't find evidence that other IPQ4019 users have the same
problem (presumably someone (e.g., in the OpenWRT community) would be
complaining about lack of SMP otherwise?), so I have to assume there are
endless firmware variants out there, as with everything in the ARM
world.

Thanks,
Brian

[1] [RFC PATCH] firmware: qcom_scm: disable SDI at boot
    https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpeace@gmail.com/



More information about the linux-arm-kernel mailing list