[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <525a6388-a4b8-3052-fe81-5aa21d8f424a@arinc9.com>
Date: Mon, 20 Mar 2023 21:09:25 +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 21:02, Krzysztof Kozlowski wrote:
> On 20/03/2023 18:57, Arınç ÜNAL wrote:
>>>> 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?
>
> More, except:
> 1. This is not clock, but sysc.
Sergio, beware.
> 2. mips sounds redundant. Do you have rt2xxx and mt7xxx chips which are ARM?
All of the SoCs, RTXXXX, MT7620, MT7621, MT7628, MT7688 are MIPS. So I
decided to call this platform MTMIPS as I've seen MediaTek use this on
other projects like U-Boot. This is what I did on my pinctrl patch
series as well.
Arınç
Powered by blists - more mailing lists