Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
From: Akhil P Oommen
Date: Fri Mar 06 2026 - 04:55:12 EST
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. :)
-Akhil.
>
> Konrad