Re: [PATCH 02/15] dt-bindings: clock: Add R8A779H0 V4M CPG Core Clock Definitions

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Magnus Damm <magnus.damm@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Cong Dang <cong.dang.xn@renesas.com>,
	Duy Nguyen <duy.nguyen.rh@renesas.com>,
	Hai Pham <hai.pham.ud@renesas.com>,
	Linh Phung <linh.phung.jy@renesas.com>,
	linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 02/15] dt-bindings: clock: Add R8A779H0 V4M CPG Core Clock Definitions
Date: Mon, 15 Jan 2024 12:39:22 +0100	[thread overview]
Message-ID: <f354cfe1-88eb-4daf-aea3-7acd2de5d106@linaro.org> (raw)
In-Reply-To: <CAMuHMdUJYH7YhQ65Bh1K8F2earTM60VwBd2=LH2vnGbaGPU53w@mail.gmail.com>

On 15/01/2024 10:27, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Tue, Jan 9, 2024 at 8:21 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 08/01/2024 16:33, Geert Uytterhoeven wrote:
>>> From: Duy Nguyen <duy.nguyen.rh@renesas.com>
>>>
>>> Add all Clock Pulse Generator Core Clock Outputs for the Renesas R-Car
>>> V4M (R8A779H0) SoC.
>>>
>>> Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com>
>>> Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> ---
>>> Changes compared to the BSP:
>>>   - Drop POST* clocks, as they are internal clocks.
>>> ---
>>>  include/dt-bindings/clock/r8a779h0-cpg-mssr.h | 96 +++++++++++++++++++
>>
>> Mediatek was able to switch to vendor,device naming scheme, so Renesas
>> should follow as well.
> 
> For new bindings, or also for existing ones?
> Doing the former means there are inconsistencies among different SoCs
> in the same family.

For the new ones. It's just naming inconsistency which does not cause
any issues. Otherwise you never move to vendor,device.h format... which
is not that critical, but in the long term brings uniformity.

> Doing the latter requires keeping the existing header files as wrappers
> including the new header files, because the binding definitions are
> part of the stable DT API.

This could also work if you want all the filenames to be consistent. I
would go only with new ones, though.

Best regards,
Krzysztof