Re: [REGRESSION] qcom PAS TZ API migration breaks GPU and modem on TrustZone without PAS (sc7180 trogdor)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing `of_node_put()` for the device node returned by `of_get_available_child_by_name()` causes a reference leak.
- [High] Unratelimited log spam and invalid `-EPROBE_DEFER` return to userspace on DRM open.
--

--- Patch [1]: [REGRESSION] qcom PAS TZ API migration breaks GPU and modem on TrustZone without PAS (sc7180 trogdor) ---
commit d49d60f9528ef181555257c9db8b08e995f71893
Author: Paul Hollinsky <phollinsky@holtechnik.com>

qcom PAS TZ API migration breaks GPU and modem on TrustZone without PAS (sc7180 trogdor)

This commit fixes boot failures on SC7180 Chromebooks caused by a recent TZ API
migration. It restores SCM availability checks for the modem and delays the PAS
check for the GPU until after discovering the zap-shader device tree node.

> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 8cd2020d4b7e9..ca5e4e560cded 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -52,6 +52,12 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname,
>  		return -ENODEV;
>  	}
>  
> +	/* We need PAS to be able to load the firmware */
> +	if (!qcom_pas_is_available()) {
> +		DRM_DEV_ERROR(dev, "PAS is not available\n");
> +		return -EPROBE_DEFER;
> +	}
> +
>  	ret = of_reserved_mem_region_to_resource(np, 0, &r);

[Severity: High]
This is a pre-existing issue, but does this early return in
zap_shader_load_mdt() leak the device node reference?

The np pointer is obtained via of_get_available_child_by_name() just before
this block, which increments the reference count. However, of_node_put(np) is
never called before returning -EPROBE_DEFER.

Because zap_available remains true, an unprivileged user can repeatedly open
the DRM device and trigger this error path on every call. Can this result in
an unbounded device node reference leak?

[Severity: High]
This is also a pre-existing issue, but does this unratelimited DRM_DEV_ERROR
in zap_shader_load_mdt() allow an unprivileged user to spam the kernel log by
repeatedly calling the DRM open syscall?

Furthermore, is it appropriate to return -EPROBE_DEFER here? Since this
function is reached during the DRM open syscall and not during the device
probe sequence, this propagates an internal driver core deferral code directly
to userspace.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260808034716.58888-1-phollinsky@holtechnik.com?part=1