Messages in this thread | | | Subject | Re: [PATCH 07/18] MIPS: DTS: jz4780: fix otg node as reported by dtbscheck | From | Zhou Yanjie <> | Date | Tue, 12 Apr 2022 17:49:07 +0800 |
| |
Hi Nikolaus,
On 2022/4/11 上午3:13, H. Nikolaus Schaller wrote: > Hi, > >> Am 10.04.2022 um 18:32 schrieb Zhou Yanjie <zhouyanjie@wanyeetech.com>: >> >> Hi folks, >> >> On 2022/4/9 下午9:53, H. Nikolaus Schaller wrote: >>>> Am 09.04.2022 um 15:44 schrieb Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>: >>>> >>>> On 09/04/2022 15:32, H. Nikolaus Schaller wrote: >>>>>> Am 09.04.2022 um 15:15 schrieb Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>: >>>>>> >>>>>> On 09/04/2022 15:05, H. Nikolaus Schaller wrote: >>>>>>>> This looks wrong, the block usually should have a specific compatible. >>>>>>>> Please mention why it does not. >>>>>>> Well, I did not even have that idea that it could need an explanation. >>>>>>> >>>>>>> There is no "ingenic,jz4780-otg" and none is needed here to make it work. >>>>>> Make it work in what terms? We talk about hardware description, right? >>>>> Yes. >>>>> >>>>>>> Therefore the generic "snps,dwc2" is sufficient. >>>>>> No, you are mixing now driver behavior (is sufficient) with hardware >>>>>> description. >>>>> No. "snps,dwc2" is a hardware description for a licensed block. >>>>> Not a driver behavior. >>>> snps,dwc2 matches the original block, not necessarily this >>>> implementation. Unless you are sure? >>> I assume. Nobody has reported an issue without having any specific jz4780 driver in place. >>> Well, that is only evidence, not bullet proof. >>> >>>>>> Most of licensed blocks require the specific compatible to >>>>>> differentiate it. >>>>> If there is a need to differentiate. >>>> No, regardless whether there is a need currently, most of them have >>>> specific compatibles, because there are some minor differences. Even if >>>> difference is not visible from programming model or wiring, it might >>>> justify it's own specific compatible. For example because maybe once >>>> that tiny difference will require some changes. >>>> >>>> Someone added the ingenic compatible, so why do you assume that one tool >>>> (bindings) is correct but other piece of code (using specific >>>> compatible) is not? You use the argument "bindings warning" which is not >>>> enough. Argument that blocks are 100% same, is good enough, if you are >>>> sure. Just use it in commit msg. But are you sure that these are the >>>> same? Same pins, same programming model (entire model, not used by Linux)? >>> The compatible ingenic,jz4780-otg was introduced in 158c774d3c64859e84dd20e04d5fb18c8d3d318e. >>> Hence I have added Yanjie for clarification why he added it in the .dts and not in the bindings. >> >> It's my fault, last year I made an OTG driver for Ingenic SoCs and sent it >> to the mailing list, and then I received some revision comments, but for >> some personal reasons I didn't continue to improve it. >> >> I'll finish these modifications as soon as possible and send them out. >> Then after they merge into the mainline, this problem will be solved. > No need to apologize. > > If you agree I can add "ingenic,jz4780-otg" to the schema file and keep > the .dts in the v2 of my series.
Sure.
Or you can wait a bit, I plan to send out new patches later today, it contains "ingenic,jz4780-otg".
> And I'll add you to the list of reviewers, so you can please comment v2 > if it is correct or if we are still missing something.
Okay, thanks!
> > Best regards and thanks, > Nikolaus
| |