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

[Gekko <graham.oconnor@gmail.com>]

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.

Graham


On 26/05/2026 00:40, Konrad Dybcio wrote:
> On 5/22/26 8:06 AM, Graham O'Connor wrote:
>> On QCS6490-based platforms booting via UEFI, the RSC hardware solver
>> is already active when the kernel takes over from the firmware. Calling
>> rpmh_probe_tcs_config() in this state reinitializes the controller
>> while the firmware is actively managing it, causing a security
>> violation and system reset.
> 
> I don't think this has been an issue so far on other platforms..
> 
> Do you have some more details?
> 
> Konrad