[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <0AE74BF9-46F1-44EC-8E5F-40EA12851AD0@goldelico.com>
Date: Wed, 13 Apr 2022 21:30:18 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Zhou Yanjie <zhouyanjie@...yeetech.com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
hminas@...opsys.com, Rob Herring <robh+dt@...nel.org>,
linux-usb@...r.kernel.org, linux-mips <linux-mips@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
<devicetree@...r.kernel.org>, dragancecavac@...oo.com,
dongsheng.qiu@...enic.com, qipengzhen <aric.pzqi@...enic.com>,
rick.tyliu@...enic.com, sernia.zhou@...mail.com,
zhenwenjin@...il.com, reimu@...omaker.com
Subject: Re: [PATCH v2 1/2] dt-bindings: dwc2: Add bindings for new Ingenic
SoCs.
Hi,
> Am 13.04.2022 um 20:55 schrieb Zhou Yanjie <zhouyanjie@...yeetech.com>:
>
> Hi Nikolaus,
>
> On 2022/4/13 下午3:22, H. Nikolaus Schaller wrote:
>> Hi,
>>
>>
>>> Am 12.04.2022 um 20:30 schrieb 周琰杰 (Zhou Yanjie) <zhouyanjie@...yeetech.com>
>>> :
>>>
>>> Add the dwc2 bindings for the JZ4775 SoC, the JZ4780 SoC, the X1000
>>> SoC, the X1600 SoC, the X1700 SoC, the X1830 SoC, and the X2000 SoC
>>> from Ingenic.
>>>
>>> Signed-off-by: 周琰杰 (Zhou Yanjie)
>>> <zhouyanjie@...yeetech.com>
>>>
>>> Acked-by: Rob Herring
>>> <robh@...nel.org>
>>>
>>> ---
>>>
>>> Notes:
>>> v1->v2:
>>> Add Rob Herring's Acked-by.
>>>
>>> Documentation/devicetree/bindings/usb/dwc2.yaml | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
>>> index 4cebce6..c6e8c0b 100644
>>> --- a/Documentation/devicetree/bindings/usb/dwc2.yaml
>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
>>> @@ -17,6 +17,13 @@ properties:
>>> oneOf:
>>> - const: brcm,bcm2835-usb
>>> - const: hisilicon,hi6220-usb
>>> + - const: ingenic,jz4775-otg
>>> + - const: ingenic,jz4780-otg
>>> + - const: ingenic,x1000-otg
>>> + - const: ingenic,x1600-otg
>>> + - const: ingenic,x1700-otg
>>> + - const: ingenic,x1830-otg
>>> + - const: ingenic,x2000-otg
>>>
>> I have merged it with my recently proposed removal of
>> ingenic,jz4780-otg in jz4780.dtsi but there was no dtbscheck
>> complaint about missing snps,dwc2.
>>
>> So I think should it be:
>>
>> - items:
>> - enum:
>> - const: ingenic,jz4775-otg
>> - const: ingenic,jz4780-otg
>> - const: ingenic,x1000-otg
>> - const: ingenic,x1600-otg
>> - const: ingenic,x1700-otg
>> - const: ingenic,x1830-otg
>> - const: ingenic,x2000-otg
>>
PS: the const: above should be removed (I hadn't run it through the compiler).
>> - const: snps,dwc2
here it is needed.
>>
>> similar to the entry for amlogic?
>>
>
>
> Or we can just remove the "snps,dwc2" from jz4780.dtsi?
Well, my recent proposal to fix dtbscheck was the other way round:
remove "ingenic,jz4780-otg" from jz4780.dtsi and leave it out here.
> I'm not too sure, but since we already have a dedicated "ingenic, jz4780-otg", it seems "snps,dwc2" is redundant.
As far as I see there is no driver specialization compatible to
"ingenic,jz4780-otg". `grep ingenic,jz4780-otg *` only shows the .dtsi (and the new .yaml).
So we need "snps,dwc2" to get any driver match and I thought the "ingenic,jz4780-otg" is redundant.
But maintainers convinced me to keep it as a dummy compatible in the .dtsi for potential future
specialization (which does not exist and seems not to be necessary). Unless I can convince them
that this is never ever needed. Which is beyond my knowledge and almost everyone.
So we can't remove the "snps,dwc2" here.
Well, we can with more work elsewhere.
You have to extend the dwc2_of_match_table to include all ingenic devices.
Therefore we now know 3 potential solutions:
a) remove "ingenic,jz4780-otg" from jz4780.dtsi (my proposal)
b) add "ingenic,jz4780-otg" to dwc2.yaml together with "snps,dwc2" (your proposal + my suggestion here)
c) add only "ingenic,jz4780-otg" to dwc2.yaml and extend the match table in drivers//usb/dwc2/params.c (new proposals)
From consistency point of view I think variant b) is the right one. a) was rejected and c) only adds redundant code.
I am open to anything as long as the dtbscheck doesn't complain any more.
BR an thanks,
Nikolaus
Powered by blists - more mailing lists