[PATCH V4 1/3] dt-bindings: sram: qcom,imem: Add Boot Stat region within IMEM

[Caleb Connolly]

On 04/05/2023 17:26, Dmitry Baryshkov wrote:
> On 04/05/2023 09:26, Krzysztof Kozlowski wrote:
>> On 04/05/2023 00:10, Caleb Connolly wrote:
>>>
>>>
>>> On 17/04/2023 16:08, Souradeep Chowdhury wrote:
>>>> +
>>>> +    properties:
>>>> +      compatible:
>>>> +        items:
>>>> +          - enum:
>>>> +              - qcom,sm8450-bootstats
>>>
>>> This region isn't exclusive to sm8450, it exists also on sdm845 and
>>> presumably other platforms. Is there any need for an SoC specific
>>> compatible?
>>
>> Yes.
>> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
>>
>> Also see many discussions on LKML about this.

Ah, thanks both for the clarification and apologies for the confusion.
My main concern is that this binding and the associated driver work just
fine on sdm845 with no additional changes. Is it acceptable then to use
the qcom,sm8450-bootstats compatible there? If not, then for someone to
enable this driver on sdm845 would require not just a patch to add the
DT node, but also a patch to dt-bindings to add a compatible AND a patch
to the driver to use it.

Based on Dmitry's response on the driver patch [1], perhaps adding the
catch-all "qcom,imem-bootstats" compatible to the driver would be
suitable. If there are SoC specific parts in the future then match data
or gating with of_device_is_compatible() can be used with the SoC
specific compatible. This is how the qcom_stats driver handles things,
would this be an OK solution for everyone?

> 
> After taking another glance at the parent device (IMEM), I start to
> think that we should not be defining the device at all. The imem has the
> SoC name in it. So I think there should be a proper driver for IMEM.
> Then it will instantiate the ABL stats platform device depending on the
> SoC compat. Also this would allow us to rewrite qcom_pil_info_init() in
> a way to query IMEM instead of poking into DT directly.

+1 for handling this automagically in driver code, I'd be happy to look
into this in the future.

[1]
https://lore.kernel.org/linux-arm-msm/35ac64ab-512d-1425-7a1b-6e8d3806c8a8@linaro.org/
> 

-- 
Kind Regards,
Caleb (they/them)