mbox series

[0/2] qcom_tzmem: Enhance Error Handling for shmbridge

Message ID 20241005140150.4109700-1-quic_kuldsing@quicinc.com (mailing list archive)
Headers show
Series qcom_tzmem: Enhance Error Handling for shmbridge | expand

Message

Kuldeep Singh Oct. 5, 2024, 2:01 p.m. UTC
This patchset addresses the tzmem driver probe failure caused by
incorrect error handling. The qcom_scm_shm_bridge_enable() SCM call
captures SCM success/failure in a0 and E_NOT_SUPPORTED in a1.

Previously, qcom_scm returned values based solely on a0, without
capturing not_supported scenario. This patchset corrects that behavior.

Along with this, add sanity checks on input parameters passed to exposed
APIs as it is missing currently.

Kuldeep Singh (1):
  firmware: qcom: qcom_tzmem: Implement sanity checks

Qingqing Zhou (1):
  firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge
    enabling

 drivers/firmware/qcom/qcom_scm.c   | 12 +++++++++++-
 drivers/firmware/qcom/qcom_tzmem.c | 17 ++++++++++++++++-
 2 files changed, 27 insertions(+), 2 deletions(-)

Comments

Bartosz Golaszewski Oct. 7, 2024, 2:25 p.m. UTC | #1
On Sat, 5 Oct 2024 at 16:02, Kuldeep Singh <quic_kuldsing@quicinc.com> wrote:
>
> This patchset addresses the tzmem driver probe failure caused by
> incorrect error handling. The qcom_scm_shm_bridge_enable() SCM call
> captures SCM success/failure in a0 and E_NOT_SUPPORTED in a1.
>
> Previously, qcom_scm returned values based solely on a0, without
> capturing not_supported scenario. This patchset corrects that behavior.
>

Ah, I guess this may be the reason for the SHM bridge enablement to
seemingly work on certain platforms and then lead to crashes when we
actually try to use it?

Bart
Kuldeep Singh Oct. 7, 2024, 7:35 p.m. UTC | #2
On 10/7/2024 7:55 PM, Bartosz Golaszewski wrote:
> On Sat, 5 Oct 2024 at 16:02, Kuldeep Singh <quic_kuldsing@quicinc.com> wrote:
>>
>> This patchset addresses the tzmem driver probe failure caused by
>> incorrect error handling. The qcom_scm_shm_bridge_enable() SCM call
>> captures SCM success/failure in a0 and E_NOT_SUPPORTED in a1.
>>
>> Previously, qcom_scm returned values based solely on a0, without
>> capturing not_supported scenario. This patchset corrects that behavior.
>>
> 
> Ah, I guess this may be the reason for the SHM bridge enablement to
> seemingly work on certain platforms and then lead to crashes when we
> actually try to use it?

This patchset corrects the behavior for handling unsupported SHM bridge scenarios.
If the SHM bridge is supported and enabled for a target, any subsequent failures
should be investigated to understand what went wrong.
I am willing to put effort in that case.