linux-kernel - Re: [PATCH 07/18] MIPS: DTS: jz4780: fix otg node as reported by dtbscheck

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 9 Apr 2022 15:44:30 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Paul Cercueil <paul@...pouillou.net>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-mips@...r.kernel.org, letux-kernel@...nphoenux.org
Subject: Re: [PATCH 07/18] MIPS: DTS: jz4780: fix otg node as reported by
 dtbscheck

On 09/04/2022 15:32, H. Nikolaus Schaller wrote:
> 
> 
>> Am 09.04.2022 um 15:15 schrieb Krzysztof Kozlowski <krzysztof.kozlowski@...aro.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?

> 
>> 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)?

Best regards,
Krzysztof