linux-kernel - Re: [PATCH 01/10] dt: bindings: clock: add mtmips SoCs clock device tree binding documentation

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:   Mon, 20 Mar 2023 20:57:40 +0300
From:   Arınç ÜNAL <arinc.unal@...nc9.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>
Cc:     linux-clk@...r.kernel.org, linux-mips@...r.kernel.org,
        tsbogend@...ha.franken.de, john@...ozen.org,
        linux-kernel@...r.kernel.org, p.zabel@...gutronix.de,
        mturquette@...libre.com, sboyd@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, matthias.bgg@...il.com,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 01/10] dt: bindings: clock: add mtmips SoCs clock device
 tree binding documentation

On 20.03.2023 20:36, Krzysztof Kozlowski wrote:
> On 20/03/2023 18:24, Sergio Paracuellos wrote:
>> Hi Krzysztof,
>>
>> On Mon, Mar 20, 2023 at 5:36 PM Krzysztof Kozlowski
>> <krzysztof.kozlowski@...aro.org> wrote:
>>>
>>> On 20/03/2023 17:18, Sergio Paracuellos wrote:
>>>> Adds device tree binding documentation for clocks and resets in the
>>>> Mediatek MIPS and Ralink SOCs. This covers RT2880, RT3050, RT3052, RT3350,
>>>> RT3883, RT5350, MT7620, MT7628 and MT7688 SoCs.
>>>
>>> Use subject prefixes matching the subsystem (which you can get for
>>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>>> your patch is touching).
>>>
>>> Subject: drop second/last, redundant "device tree binding
>>> documentation". The "dt-bindings" prefix is already stating that these
>>> are bindings.
>>
>> Sure, will do. Sorry for the inconvenience.
>>
>>> (BTW, that's the longest redundant component I ever saw)
>>
>> I thought it was better to just list compatible strings inside one
>> single file than adding the same binding in multiple files.
> 
> I don't understand how this is answers about redundant piece of subject.
> Amount of files are not related to repeating pieces of subject prefix.
> 
>>
>>>
>>>>
>>>> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@...il.com>
>>>> ---
>>>>   .../bindings/clock/mtmips-clock.yaml          | 68 +++++++++++++++++++
>>>>   1 file changed, 68 insertions(+)
>>>>   create mode 100644 Documentation/devicetree/bindings/clock/mtmips-clock.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/mtmips-clock.yaml b/Documentation/devicetree/bindings/clock/mtmips-clock.yaml
>>>> new file mode 100644
>>>> index 000000000000..c92969ce231d
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/mtmips-clock.yaml
>>>
>>> Filename matching compatible, so vendor prefix and device name (or
>>> family of names).
>>
>> I used mtmips here but list compatibles starting with ralink. As I
>> have said in the cover letter I am inspired by the last merged pinctrl
>> series for these SoCs.
>> See:
>> - https://lore.kernel.org/linux-gpio/e9e6ad87-2db5-9767-ff39-64a302b06185@arinc9.com/T/#t
> 
> 21 patches, so what exactly I should see (except that I was involved in
> that discussions)?
> 
> Plus nothing from this thread warrants here exception from naming style.
> 
> 
>>
>> Not all of compatible currently exist.
> 
> Then clearly state this.
> 
>> All of these are at the end the
>> way we can properly match compatible-data to write a proper driver.
>> The current ralink dtsi files which are in tree now
>> are totally incomplete and not documented so we are planning to align
> 
> Nothing like this was said in commit msg, so how can we know?
> 
>> all of this with openWRT used files and others soon. That's the reason
>> we are not touching
>> 'arch/mips/boot/dts' at all now. I don't think anybody is using any of
>> this but mt7621 which is properly completed and documented.
> 
> Anyway, none of this explains exception from naming convention - vendor,
> device or family name.

Would mediatek,mtmips-clock.yaml make sense?

Arınç