1. Patchew
  2. linux
  3. View series

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

Christian Marangi posted 1 patch 1 week, 4 days ago 
.../devicetree/bindings/arm/qcom.yaml         | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
[PATCH] dt-bindings: arm: qcom: add ipq8064 board variants
Posted by Christian Marangi 1 week, 4 days ago 
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
Posted by Konrad Dybcio 1 week, 4 days ago 
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
Posted by Christian Marangi 1 week, 4 days ago 
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
Posted by Rob Herring 1 week, 4 days ago 
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
Posted by Christian Marangi 1 week, 4 days ago 
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
Posted by Konrad Dybcio 1 week, 3 days ago 
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
>

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.