Claude review: firmware: qcom: Add a PAS TEE service

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

The OP-TEE backend implementation using the TEE bus client driver infrastructure.

**`qcom_pas_tee_get_rsc_table` has a questionable two-call pattern:**
```c
ret = tee_client_invoke_func(data->ctx, &inv_arg, param);
if (ret < 0 || inv_arg.ret != 0) { ... }

if (param[1].u.memref.size) {
    /* allocate SHM, copy input, call again */
    ...
}
```
The first call is made with `param[1].u.memref.shm` being NULL (no shared memory allocated). This appears to be a "query size" call. However, the `attr` is set to `TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT` without any backing memory. Whether this is valid depends on the OP-TEE TA implementation. If the TA tries to access the memref on the first call, it could fail. The pattern assumes the TA will return the required size in `param[1].u.memref.size` without accessing the buffer, which should be documented.

**`DEFINE_FREE(shm_free, ...)` scope issue:**
```c
DEFINE_FREE(shm_free, struct tee_shm *, tee_shm_free(_T))
```
This `DEFINE_FREE` macro is defined at file scope but `tee_shm_free` accepts NULL gracefully (it's a no-op for NULL), and `IS_ERR_OR_NULL` is checked. However, when the cleanup runs, if `rt_shm` was set to NULL after the `IS_ERR_OR_NULL` check (`rt_shm = NULL`), `tee_shm_free(NULL)` will be called, which should be fine. But the flow is confusing: `rt_shm` is set to NULL in the error path to prevent the `__free` cleanup from freeing it, but then the function returns `ERR_PTR(-ENOMEM)` which will trigger cleanup... Actually, looking more carefully:
```c
if (IS_ERR_OR_NULL(rt_shm)) {
    rt_shm = NULL;
    return ERR_PTR(-ENOMEM);
}
```
Setting `rt_shm = NULL` before returning prevents the `__free(shm_free)` cleanup from freeing an error pointer. This is correct but quite subtle.

**TEE probe sets ops without checking for existing registration:**
```c
qcom_pas_ops_tee.dev = dev;
qcom_pas_ops_register(&qcom_pas_ops_tee);
```
If the SCM backend already registered (which it will on platforms with both SCM and OP-TEE), this will just print an error and silently fail. The TEE driver probe still returns success (`return ret` where `ret` is 0). This means the TEE driver will appear to have probed successfully but won't actually be used. Consider returning an error from `qcom_pas_ops_register()` so the TEE probe can handle it, or better yet, design for backend priority/switchover.

**`depends on !CPU_BIG_ENDIAN`**: The Kconfig has this restriction. The commit message doesn't explain why. Presumably it's because the TEE ABI uses `lower_32_bits`/`upper_32_bits` for address splitting which assumes little-endian wire format. This should be documented.

---
Generated by Claude Code Patch Reviewer