Re: [PATCH 4/4] media: qcom: camss: Report hardware version via media controller

[Konrad Dybcio]

On 7/21/26 9:55 AM, Loic Poulain wrote:
> On Mon, Jul 20, 2026 at 11:12 AM Konrad Dybcio
> <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>>
>> On 7/17/26 4:20 PM, Loic Poulain wrote:
>>> Populate media_dev.hw_revision with the top-level CAMSS hardware version
>>> so that user space can query the exact hardware variant through the media
>>> controller (e.g. via media-ctl or MEDIA_IOC_DEVICE_INFO). This can help
>>> identify the platform variant and adapt behaviour accordingly, for example
>>> allowing libcamera to apply quirks or enable features that cannot be
>>> discovered through standard V4L2 or media-controller APIs.
>>
>> [...]
>>
>>> +static void camss_read_version(struct camss *camss)
>>> +{
>>> +     u32 hw_version;
>>> +
>>> +     if (!camss->top_base || !camss->res->pm_clks[0])
>>> +             return;
>>> +
>>> +     if (pm_runtime_resume_and_get(camss->dev))
>>> +             return;
>>> +
>>> +     hw_version = readl_relaxed(camss->top_base + CAMSS_HW_VERSION);
>>> +
>>> +     pm_runtime_put_sync(camss->dev);
>>
>> I think non-sync is fine here
> 
> Using asynchronous PM may result in the runtime suspend ("work") never
> being executed if the probe function fails later (read version called
> from probe). From my understanding, a subsequent pm_runtime_disable()
> in the error path would cancel the pending suspend request, leaving
> the runtime PM state in a non-symmetrical (unbalanced) state.

Got it

Konrad