1. Patchew
  2. linux
  3. View series

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

Jingyi Wang posted 1 patch 1 month ago 
Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
1 file changed, 1 insertion(+)
[PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Jingyi Wang 1 month ago 
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
           - qcom,msm8226-qfprom
           - qcom,msm8916-qfprom
           - qcom,msm8917-qfprom

---
base-commit: fc7b1a72c6cd5cbbd989c6c32a6486e3e4e3594d
change-id: 20260305-knp-qfprom-binding-efcff6ea9b7c

Best regards,
-- 
Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Srinivas Kandagatla 4 weeks, 1 day ago 
On Thu, 05 Mar 2026 22:40:41 -0800, Jingyi Wang wrote:
> Document compatible string for the QFPROM on Kaanapali platform.
> 
> 

Applied, thanks!

[1/1] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
      commit: c693038ce48b93f73294f158e8b26b1119d226d4

Best regards,
-- 
Srinivas Kandagatla <srini@kernel.org>
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Krzysztof Kozlowski 1 month ago 
On 06/03/2026 07:40, 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(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Akhil P Oommen 1 month ago 
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.

-Akhil.

>            - qcom,msm8226-qfprom
>            - qcom,msm8916-qfprom
>            - qcom,msm8917-qfprom
> 
> ---
> base-commit: fc7b1a72c6cd5cbbd989c6c32a6486e3e4e3594d
> change-id: 20260305-knp-qfprom-binding-efcff6ea9b7c
> 
> Best regards,
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Krzysztof Kozlowski 1 month ago 
On 06/03/2026 07:55, 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

Yes, you need.

Best regards,
Krzysztof
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Konrad Dybcio 1 month ago 
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)

Konrad
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Akhil P Oommen 1 month ago 
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
Re: [PATCH] dt-bindings: nvmem: qfprom: Add Kaanapali compatible
Posted by Konrad Dybcio 1 month ago 
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@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. :)

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

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.