[PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[Christian Marangi]

Document QCOM ipq8064 board variants ipq8062, ipq8065, ipq8066,
ipq8068, ipq8069 now matched by the QCOM cpufreq nvmem driver if
socinfo can't derive the variant from SMEM.

Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 .../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 18b5ed044f9f..0eb1619fede8 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -299,12 +299,32 @@ properties:
               - qcom,ipq5424-rdp466
           - const: qcom,ipq5424
 
+      - items:
+          - const: qcom,ipq8062
+          - const: qcom,ipq8064
+
       - items:
           - enum:
               - mikrotik,rb3011
               - qcom,ipq8064-ap148
           - const: qcom,ipq8064
 
+      - items:
+          - const: qcom,ipq8065
+          - const: qcom,ipq8064
+
+      - items:
+          - const: qcom,ipq8066
+          - const: qcom,ipq8064
+
+      - items:
+          - const: qcom,ipq8068
+          - const: qcom,ipq8064
+
+      - items:
+          - const: qcom,ipq8069
+          - const: qcom,ipq8064
+
       - items:
           - enum:
               - qcom,ipq8074-hk01
-- 
2.51.0

Re: [PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[Konrad Dybcio]

On 11/20/25 2:54 PM, Christian Marangi wrote:
> Document QCOM ipq8064 board variants ipq8062, ipq8065, ipq8066,
> ipq8068, ipq8069 now matched by the QCOM cpufreq nvmem driver if
> socinfo can't derive the variant from SMEM.
> 
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
>  .../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 18b5ed044f9f..0eb1619fede8 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -299,12 +299,32 @@ properties:
>                - qcom,ipq5424-rdp466
>            - const: qcom,ipq5424
>  
> +      - items:
> +          - const: qcom,ipq8062
> +          - const: qcom,ipq8064

Since 'items' requires that all items are present (and in this order),
we would normally have a board name go first.. but I suppose this is
some sort of a fix to the issue that sparked this (posting the link
for others to have more context)

But since these SoCs do exist, I wouldn't say this is necessarily
wrong..

https://lore.kernel.org/linux-arm-msm/20251105112136.371376-2-ansuelsmth@gmail.com/

Konrad

Re: [PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[Christian Marangi]

On Thu, Nov 20, 2025 at 04:25:37PM +0100, Konrad Dybcio wrote:
> On 11/20/25 2:54 PM, Christian Marangi wrote:
> > Document QCOM ipq8064 board variants ipq8062, ipq8065, ipq8066,
> > ipq8068, ipq8069 now matched by the QCOM cpufreq nvmem driver if
> > socinfo can't derive the variant from SMEM.
> > 
> > Suggested-by: Rob Herring <robh@kernel.org>
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> >  .../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > index 18b5ed044f9f..0eb1619fede8 100644
> > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > @@ -299,12 +299,32 @@ properties:
> >                - qcom,ipq5424-rdp466
> >            - const: qcom,ipq5424
> >  
> > +      - items:
> > +          - const: qcom,ipq8062
> > +          - const: qcom,ipq8064
> 
> Since 'items' requires that all items are present (and in this order),
> we would normally have a board name go first.. but I suppose this is
> some sort of a fix to the issue that sparked this (posting the link
> for others to have more context)
> 
> But since these SoCs do exist, I wouldn't say this is necessarily
> wrong..
>

Well we can see this as a ""template"" for device that might be added
using the ipq8062 or ipq8065 compatible.

When device with that variant will be added we would have to just add an
enum with the real device name on top of it (as first element).

Honestly I should have added these compatible long time ago as on
OpenWrt we have tons of device that are ipq8062 or ipq8065 with the
compatible structure

"device,name", "qcom,ipq8065", "qcom,ipq8064".

I feel it might be wrong to simply add to the list "qcom,ipq8065"
without the "qcom,ipq8064" part.

> https://lore.kernel.org/linux-arm-msm/20251105112136.371376-2-ansuelsmth@gmail.com/
>

Maybe I should add a Ref: tag referencing that?

-- 
	Ansuel

Re: [PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[Rob Herring]

On Thu, Nov 20, 2025 at 04:31:47PM +0100, Christian Marangi wrote:
> On Thu, Nov 20, 2025 at 04:25:37PM +0100, Konrad Dybcio wrote:
> > On 11/20/25 2:54 PM, Christian Marangi wrote:
> > > Document QCOM ipq8064 board variants ipq8062, ipq8065, ipq8066,
> > > ipq8068, ipq8069 now matched by the QCOM cpufreq nvmem driver if
> > > socinfo can't derive the variant from SMEM.
> > > 
> > > Suggested-by: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > ---
> > >  .../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > index 18b5ed044f9f..0eb1619fede8 100644
> > > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > @@ -299,12 +299,32 @@ properties:
> > >                - qcom,ipq5424-rdp466
> > >            - const: qcom,ipq5424
> > >  
> > > +      - items:
> > > +          - const: qcom,ipq8062
> > > +          - const: qcom,ipq8064
> > 
> > Since 'items' requires that all items are present (and in this order),
> > we would normally have a board name go first.. but I suppose this is
> > some sort of a fix to the issue that sparked this (posting the link
> > for others to have more context)
> > 
> > But since these SoCs do exist, I wouldn't say this is necessarily
> > wrong..
> >
> 
> Well we can see this as a ""template"" for device that might be added
> using the ipq8062 or ipq8065 compatible.
> 
> When device with that variant will be added we would have to just add an
> enum with the real device name on top of it (as first element).
> 
> Honestly I should have added these compatible long time ago as on
> OpenWrt we have tons of device that are ipq8062 or ipq8065 with the
> compatible structure
> 
> "device,name", "qcom,ipq8065", "qcom,ipq8064".

If you don't you have any boards yet, you can do:

items:
  - description: ...
  - const: qcom,ipq8065
  - const: qcom,ipq8064

Just to prevent skipping a board compatible.

But you said you have tons of devices, so...

Rob

Re: [PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[Christian Marangi]

On Thu, Nov 20, 2025 at 11:41:19AM -0600, Rob Herring wrote:
> On Thu, Nov 20, 2025 at 04:31:47PM +0100, Christian Marangi wrote:
> > On Thu, Nov 20, 2025 at 04:25:37PM +0100, Konrad Dybcio wrote:
> > > On 11/20/25 2:54 PM, Christian Marangi wrote:
> > > > Document QCOM ipq8064 board variants ipq8062, ipq8065, ipq8066,
> > > > ipq8068, ipq8069 now matched by the QCOM cpufreq nvmem driver if
> > > > socinfo can't derive the variant from SMEM.
> > > > 
> > > > Suggested-by: Rob Herring <robh@kernel.org>
> > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > ---
> > > >  .../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
> > > >  1 file changed, 20 insertions(+)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > > index 18b5ed044f9f..0eb1619fede8 100644
> > > > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > > > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > > > @@ -299,12 +299,32 @@ properties:
> > > >                - qcom,ipq5424-rdp466
> > > >            - const: qcom,ipq5424
> > > >  
> > > > +      - items:
> > > > +          - const: qcom,ipq8062
> > > > +          - const: qcom,ipq8064
> > > 
> > > Since 'items' requires that all items are present (and in this order),
> > > we would normally have a board name go first.. but I suppose this is
> > > some sort of a fix to the issue that sparked this (posting the link
> > > for others to have more context)
> > > 
> > > But since these SoCs do exist, I wouldn't say this is necessarily
> > > wrong..
> > >
> > 
> > Well we can see this as a ""template"" for device that might be added
> > using the ipq8062 or ipq8065 compatible.
> > 
> > When device with that variant will be added we would have to just add an
> > enum with the real device name on top of it (as first element).
> > 
> > Honestly I should have added these compatible long time ago as on
> > OpenWrt we have tons of device that are ipq8062 or ipq8065 with the
> > compatible structure
> > 
> > "device,name", "qcom,ipq8065", "qcom,ipq8064".
> 
> If you don't you have any boards yet, you can do:
> 
> items:
>   - description: ...
>   - const: qcom,ipq8065
>   - const: qcom,ipq8064
> 
> Just to prevent skipping a board compatible.
> 
> But you said you have tons of devices, so...
> 

Yes the problem is that it might take a while for the DTS to be picked
so maybe it's better to push for the description solution?

-- 
	Ansuel

Re: [PATCH] dt-bindings: arm: qcom: add ipq8064 board variants

[Konrad Dybcio]

On 11/20/25 11:49 PM, Christian Marangi wrote:
> On Thu, Nov 20, 2025 at 11:41:19AM -0600, Rob Herring wrote:
>> On Thu, Nov 20, 2025 at 04:31:47PM +0100, Christian Marangi wrote:
>>> On Thu, Nov 20, 2025 at 04:25:37PM +0100, Konrad Dybcio wrote:
>>>> On 11/20/25 2:54 PM, Christian Marangi wrote:
>>>>> Document QCOM ipq8064 board variants ipq8062, ipq8065, ipq8066,
>>>>> ipq8068, ipq8069 now matched by the QCOM cpufreq nvmem driver if
>>>>> socinfo can't derive the variant from SMEM.
>>>>>
>>>>> Suggested-by: Rob Herring <robh@kernel.org>
>>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>>>> ---
>>>>>  .../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
>>>>>  1 file changed, 20 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>> index 18b5ed044f9f..0eb1619fede8 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>> @@ -299,12 +299,32 @@ properties:
>>>>>                - qcom,ipq5424-rdp466
>>>>>            - const: qcom,ipq5424
>>>>>  
>>>>> +      - items:
>>>>> +          - const: qcom,ipq8062
>>>>> +          - const: qcom,ipq8064
>>>>
>>>> Since 'items' requires that all items are present (and in this order),
>>>> we would normally have a board name go first.. but I suppose this is
>>>> some sort of a fix to the issue that sparked this (posting the link
>>>> for others to have more context)
>>>>
>>>> But since these SoCs do exist, I wouldn't say this is necessarily
>>>> wrong..
>>>>
>>>
>>> Well we can see this as a ""template"" for device that might be added
>>> using the ipq8062 or ipq8065 compatible.
>>>
>>> When device with that variant will be added we would have to just add an
>>> enum with the real device name on top of it (as first element).
>>>
>>> Honestly I should have added these compatible long time ago as on
>>> OpenWrt we have tons of device that are ipq8062 or ipq8065 with the
>>> compatible structure
>>>
>>> "device,name", "qcom,ipq8065", "qcom,ipq8064".
>>
>> If you don't you have any boards yet, you can do:
>>
>> items:
>>   - description: ...
>>   - const: qcom,ipq8065
>>   - const: qcom,ipq8064
>>
>> Just to prevent skipping a board compatible.
>>
>> But you said you have tons of devices, so...
>>
> 
> Yes the problem is that it might take a while for the DTS to be picked
> so maybe it's better to push for the description solution?

DT depends on bindings, it's not so stringent the other way around

Konrad
>