Re: [PATCH v7 4/7] pmdomain: rockchip: Add smc call to inform firmware

[Shawn Lin <shawn.lin@rock-chips.com>]

Hi Heiko, Steven

在 2025/2/18 4:50, Heiko Stübner 写道:
> Am Montag, 17. Februar 2025, 18:10:32 MEZ schrieb Steven Price:
>> On 17/02/2025 15:16, Heiko Stübner wrote:
>>> Hi Steven,
>>>
>>> Am Montag, 17. Februar 2025, 15:47:21 MEZ schrieb Steven Price:
>>>> On 05/02/2025 06:15, Shawn Lin wrote:
>>>>> Inform firmware to keep the power domain on or off.
>>>>>
>>>>> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>>>>> ---
>>>>
>>>> This patch is causing my Firefly RK3288 to fail to boot, it hangs
>>>> shortly after reaching user space, but the bootup messages include the
>>>> suspicious line "Bad mode in prefetch abort handler detected".
>>>> I suspect the firmware on this board doesn't support this new SMC
>>>> correctly. Reverting this patch on top of linux-next gets everything
>>>> working again.
>>>
>>> Is your board actually running some trusted firmware?
>>
>> Not as far as I know.
>>
>>> Stock rk3288 never had tf-a / psci [0], I did work on that for a while,
>>> but don't think that ever took off.
>>>
>>> I'm wondering who the smcc call is calling, but don't know about
>>> about smcc stuff.
>>
>> Good question - it's quite possible things are blowing up just because
>> there's nothing there to handle the SMC. My DTB is as upstream:
>>
>>          cpus {
>>                  #address-cells = <0x01>;
>>                  #size-cells = <0x00>;
>>                  enable-method = "rockchip,rk3066-smp";
>>                  rockchip,pmu = <0x06>;
>>
>> I haven't investigated why this code is attempting to call an SMC on
>> this board.
> 
> I guess the why is easy, something to do with suspend :-) .
> 
> I did go testing a bit, booting a rk3288-veyron produces the same issue
> you saw, likely due to the non-existent trusted-firmware.
> 
> On the arm64-side, I tried a plethora of socs + tfa-versions,
> 
>    rk3328: v2.5 upstream(?)-tf-a
>    rk3399: v2.9 upstream-tf-a
>    px30: v2.4+v2.9 upstream-tf-a
>    rk3568: v2.3 vendor-tf-a
>    rk3588: v2.3 vendor-tf-a
> 
> and all ran just fine.
> So it really looks like the smcc call going to some unset location is
> the culprit.
> 
> Looking at other users of arm_smcc_smc, most of them seem to be handled
> unguarded, but some older(?) arm32 boards actually check their DTs for an
> optee node before trying their smc-call.
> 
> I guess in the pm-domain case, we could just wrap the call with:
> 	if(arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_NONE)
> 

Thanks for the report and helping find out the cause!

@Ulf, if the solution above seems reasonable to you, I can cook a fix-up
patch.

> I've checked in my boards now, and all the boards mentioned above seem
> to handle this well with smccc-versions of at least 0x10002 .
> 
> Heiko
> 
> 
>