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

[Akhil P Oommen <akhilpo@oss.qualcomm.com>]

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@oss.qualcomm.com>
>>> ---
>>>  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. :)

-Akhil.

> 
> Konrad