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

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

Patch Review

This is the core abstraction layer. Several concerns:

**Global singleton with weak synchronization.** `ops_ptr` is a bare global pointer (`qcom_pas.c:13`):
```c
struct qcom_pas_ops *ops_ptr;
```
While `smp_load_acquire`/`smp_store_release` pairs are used, there's no protection against concurrent use during unregister. If `qcom_pas_ops_unregister()` is called while a client is mid-call through `ops_ptr->init_image(...)`, this is a use-after-free. There's no refcounting or RCU protection.

**No `-EPROBE_DEFER` return from non-`is_available` functions.** Functions like `qcom_pas_init_image()` return `-ENODEV` when `ops_ptr` is NULL, but the client likely already checked `qcom_pas_is_available()`. Still, a TOCTOU gap exists between checking availability and calling the function.

**`qcom_pas_context` exposed in public header.** The `qcom_pas_context` struct at `include/linux/firmware/qcom/qcom_pas.h:12-21` exposes internal fields like `ptr`, `phys`, `use_tzmem` that are backend-specific. This should ideally be opaque to consumers.

**`get_rsc_table` ops return type is `void *` but the public API returns `struct resource_table *`.** In `qcom_pas.h:36`:
```c
void *(*get_rsc_table)(struct device *dev, ...);
```
But `qcom_pas_get_rsc_table()` in `qcom_pas.c:149` returns `struct resource_table *`. This implicit cast works but is sloppy — the ops callback should return `struct resource_table *` for type safety.

**`pas_id` parameter inconsistency.** Some functions take `pas_id` as a parameter (e.g., `qcom_pas_init_image`, `qcom_pas_shutdown`) while others get it from the context (e.g., `qcom_pas_get_rsc_table`, `qcom_pas_prepare_and_auth_reset`). This is inherited from the old API but worth noting as confusing.

---
Generated by Claude Code Patch Reviewer