Re: [RFC PATCH 0/3] power: sequencing: qcom-wcn: support SW_CTRL wake IRQ

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 10/14/26 2:19 PM, Linghui Wu wrote:
> Some WCN3990-family designs connect the SW_CTRL output to a GPIO on the
> application processor. On Shikra, the WCN3988 SW_CTRL signal is connected
> to GPIO88 and is used through the MGPI/AOSS hardware path to request the
> required RF clocks.
> 
> Qualcomm downstream kernels configure this path through
> msm_gpio_mpm_wake_set(), but upstream does not provide an equivalent API.

This information is not useful to the reader who doesn't follow the
Qualcomm downstream kernels.

> This series models SW_CTRL as a dedicated wake IRQ. Requesting the GPIO IRQ
> resource enables POWER_SAVE_WAKEUP_ENABLE in Qualcomm TLMM when
> WAKEUP_PRESENT is advertised, while the PM core keeps the IRQ disabled
> during normal operation and arms it for system suspend.

This starts off good, but zooms in too much on the specifics, instead
of the functional outcome.

> This is an RFC because the intended hardware and software model still
> needs confirmation. In particular, please advise whether SW_CTRL should
> be represented as an AP wake source using dev_pm_set_dedicated_wake_irq(),
> or whether Linux only needs an interface to explicitly configure the
> TLMM/MGPI power-save path.

You threw a lot of Qualcomm TLAs at potentially non-Qualcomm reviewers,
so it's not really possible for them to give you this advice.

> The series documents the named wakeup interrupt for the WCN PMU binding,
> implements dedicated wake IRQ handling in the Qualcomm WCN power
> sequencer, and enables it on the Shikra CQM, CQS and IQS EVKs. On this
> base, CQM and CQS share shikra-cqm-som.dtsi, while IQS uses
> shikra-iqs-som.dtsi.

The second sentence brings no value.

> Testing:
> - scripts/checkpatch.pl --strict: passed
> - dt-binding-check: passed
> - dtb-check: passed
> - sparse-check: passed
> - Shikra CQM, CQS and IQS DTB builds: passed

The above cases are implicitly expected and shouldn't be listed out.
> - QIPL validation of the equivalent qcom-6.18.y implementation: passed

This is a useless test on a year-old kernel with a million patches on top
that doesn't reflect whether the change works on the target tree (which
is approximately linux-next/master). You must test your changes on the
base that you intend the patch to be applied to.

> An earlier experiment confirmed that requesting GPIO88 as an IRQ changes
> TLMM_GPIO_INTR_CFG88 from 0x942 to 0x9c2, setting
> POWER_SAVE_WAKEUP_ENABLE.
> 
> Linghui Wu (3):
>   dt-bindings: power: sequencing: qcom-wcn: document wakeup-source
>   power: sequencing: qcom-wcn: support SW_CTRL wake IRQ
>   arm64: dts: qcom: shikra: enable WCN SW_CTRL wakeup
> 
>  .../bindings/regulator/qcom,wcn3990-pmu.yaml  | 22 ++++++++++++++
>  arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi  |  4 +++
>  arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi  |  4 +++
>  drivers/power/sequencing/pwrseq-qcom-wcn.c    | 30 +++++++++++++++++++
>  4 files changed, 60 insertions(+)
> 
> 
> base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a

You must base your changes on linux-next, otherwise your base is
effectively 3 months behind the current developments.

Konrad