On Mon, Jul 29, 2024 at 11:58 AM Johan Hovold <johan+linaro@xxxxxxxxxx> wrote:
>
> This reverts commit 6612103ec35af6058bb85ab24dae28e119b3c055.
>
> Using the "TZ allocator" for qcseecom breaks efivars on machines like
> the Lenovo ThinkPad X13s and x1e80100 CRD:
>
> qcom_scm firmware:scm: qseecom: scm call failed with error -22
>
> Reverting to the 6.10 state makes qseecom work again.
>
> Fixes: 6612103ec35a ("firmware: qcom: qseecom: convert to using the TZ allocator")
> Cc: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> Signed-off-by: Johan Hovold <johan+linaro@xxxxxxxxxx>
> ---
> Cc: regressions@xxxxxxxxxxxxxxx
>
> #regzbot introduced: 6612103ec35a
>
How about at least giving me the chance to react to the report and fix
it instead of reverting it right away?
Are there any other messages about SHM bridge/SCM calls in the kernel log?
Do you have QCOM_TZMEM_MODE_GENERIC=y or QCOM_TZMEM_MODE_SHM_BRIDGE=y
in your config? If the latter: can you try changing it to the former
and retest?
>
> It's a little frustrating to find that no-one tested this properly or
> even noticed the regression for the past month that this has been
> sitting in linux-next.
>
I have tested many platforms and others have done the same but
unfortunately cannot possibly test every single use-case on every
platform. This is what next is for after all.
> Looks like Maximilian may have hit this with v9 too:
>
> https://lore.kernel.org/lkml/CAMRc=Mf_pvrh2VMfTVE-ZTypyO010p=to-cd8Q745DzSDXLGFw@xxxxxxxxxxxxxx/
>
> even if there were further issues with that revision.
This is a different issue that was fixed in a later iteration.
>
> Johan
>
Bartosz
