Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible

[Konrad Dybcio]

On 3/6/26 10:54 AM, Akhil P Oommen wrote:
> On 3/6/2026 2:40 PM, Konrad Dybcio wrote:
>> On 3/6/26 7:55 AM, Akhil P Oommen wrote:
>>> On 3/6/2026 12:10 PM, Jingyi Wang wrote:
>>>> Document compatible string for the QFPROM on Kaanapali platform.
>>>>
>>>> Signed-off-by: Jingyi Wang <jingyi.wang@xxxxxxxxxxxxxxxx>
>>>> ---
>>>>  Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
>>>> index 839513d4b499..2ab047f2bb69 100644
>>>> --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
>>>> +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
>>>> @@ -26,6 +26,7 @@ properties:
>>>>            - qcom,ipq8064-qfprom
>>>>            - qcom,ipq8074-qfprom
>>>>            - qcom,ipq9574-qfprom
>>>> +          - qcom,kaanapali-qfprom
>>>
>>> A question to the maintainers.
>>>
>>> Do we need a new compatible for every chipset? If there are no KMD
>>> facing differences in the HW, can we use an existing compatible string,
>>> like sm8750's in this case?
>>>
>>> The fuse definitions (which map to nvmem cells) will obviously differ
>>> between chipsets, but I am not sure if this alone warrants introducing a
>>> new compatible string.
>>
>> This is to prevent the case where it later turns out that QFPROM on 8750
>> is deeply flawed under certain conditions and needs to have workarounds
>> applied retroactively (because we're pinky-promise working towards stable
>> DT ABI)
> 
> But this is a super simple HW IP, so make an exception for this? In the
> worst case, use a SoC related compatible in the driver for quirks?
> 
> I am just trying to see if there is a way to avoid this dependency for
> the DT series. :)

I think this is the incorrect level of zoom - yes, it's annoying, but we
have probably 10-20 more places where we need a 'meaningless' compatible.

The quick solution to getting over this, would be to let platform
maintainers (qc, mtk, nv..) take such simple patches via the same trees
that grab DT changes - and I think there's been some discussion around
that

Konrad