Re: [PATCH 1/6] soc: qcom: rpmh-rsc: Skip TCS init when RSC is managed by firmware

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

On 5/27/26 10:30 PM, Gekko wrote:
> Hi Konrad,
> 
> This one is confusing.
> 
> I started the bring-up on this board on gentoo-sources 6.18.18 but the board would not boot. After an almost subliminal flash of tux the board would lock every time.I found the solution from PostmarketOS who obviously faced the same issue which formed the genesis of this patch. With this patch applied the board booted fine so I've applied it ever since.
> 
> However, as a result of your response here I tried booting my current kernel (gentoo-sources 7.0.10) without the patch and to my surprise it booted just fine. This leaves a few options, including:
> 1) the kernel source has changed
> 2) this is a firmware issue and a firmware update fixed it
> 3) It's a timing issue.
> 
> To eliminate 2 I would have to test 6.18.18 with the current firmware, then regress the firmware and test again. The do the same with 7.0.10. I can't honestly recall whether the firmware upgrade was before or after this issue first appeared.
> 
> If it's a timing issue it's a bit more concerning. If the kernel is taking slightly longer to initialise before calling rpmh_probe_tcs_config() then it may just be missing the solver activation, everything appears to work and nobody is any the wiser. If the existing solver code doesn't deal with early firmware TCS initialisation then it could, under some circumstances, lead to the security reset that I was seeing. This patch specifically tests for that case.
> 
> Based on the AI review feedback I've also modified the patch to not simply return early but to just skip the sensitive parts of the code to allow any other setup to complete normally.
> 
> My current objective evidence is that the board boots without this patch and it's quite possible this patch is unnecessary if the above is incorrect.

I would skew towards this being a firmware issue. But I'm interested
in any findings you encounter.

Maybe +Maulik could know more

Konrad