[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bdc82b4a-f1a9-0372-5a57-200a422b1b70@arinc9.com>
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ç
Powered by blists - more mailing lists