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

[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 at linaro.org>
> >>> Signed-off-by: Shawn Lin <shawn.lin at 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)

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