From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 98B80C3DA7F for ; Mon, 5 Aug 2024 05:23:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=+AOe1X1BK2T9Nhb61hULdxwB8+O9eooFF234E3lK5bc=; b=KQvS8GK9IcPyBQxMjzmq0XHzPS KkmYfC/dyCWRR5lXyE/kJJfcRMpJhAm/oodx35zG+t3mDbk7B8Spa5vo89haNYqHwY4f3H+bVEORY MIWNUxUMXkhSRkFSHhkjoQOR0V+de8L/4ghA2IJXbANXGrj9enaHntr154vjJkReaQPmpS8HMdZIc 6htZ5ZdNp8iaMDtSZXwci7i0ev6dxP5x/Xm68uyJ5IM26PDtcVTJ7xIJ9PrQKjP3b5nWm0155bvc5 PCo2UZwdtTXCbSEM1o7P3Coo8GoCcp7YwIxn2zWDVTiiLrT5oe8w2p6Jp69y+KljDYxlBlQHQeqHx +Pm1EWTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1saqBh-0000000EgX6-2Yj1; Mon, 05 Aug 2024 05:23:17 +0000 Received: from mail.manjaro.org ([2a01:4f8:c0c:51f3::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1saqB8-0000000EgPY-1xKk; Mon, 05 Aug 2024 05:22:44 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1722835360; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+AOe1X1BK2T9Nhb61hULdxwB8+O9eooFF234E3lK5bc=; b=gu6gyClfqFB4PQ+WxAd5h9p9n4YjVkd+J9VwMd9c2CwEAg18JJ547LmzTGDdhxeKXwKUwe IHWdr43Kqif02h2PBhgyxI3bMsGEuv9PMOTvZLB4bBU8+ca59vRfuZht0b7iDZdEEsgGWk Apy+y47XAEB/JuXSsxmH+9fTjPFYaU+iRO+66bYHqBV9EIjtnwdNDuGevmKuD5r+c3pPw7 LJHW23x+jMMn3rKEKswV6A69D2wOdvM4KvF85xQlXU7gJbGlbbzVFn2wta5Ddalv+IvoT+ m+eSIbi3oVo/u7+YIyYdHRV3Mk3BXtjsMinyzs7WBit9ZxUIUnqDDkMrLop2rw== Date: Mon, 05 Aug 2024 07:22:34 +0200 From: Dragan Simic To: =?UTF-8?Q?Heiko_St=C3=BCbner?= Cc: Yao Zi , Krzysztof Kozlowski , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Greg Kroah-Hartman , Jiri Slaby , Chris Morgan , Jonas Karlman , Tim Lunn , Andy Yan , Muhammed Efe Cetin , Jagan Teki , Ondrej Jirman , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Subject: Re: [PATCH 3/4] arm64: dts: rockchip: Add base DT for rk3528 SoC In-Reply-To: <10256980.nnTZe4vzsl@diego> References: <20240803125510.4699-2-ziyao@disroot.org> <2408413.9XhxPE3A7Q@diego> <81147f0205c2a9555c9c64e4f7a69b6b@manjaro.org> <10256980.nnTZe4vzsl@diego> Message-ID: <1da29af645d98be85b422208136e8150@manjaro.org> X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240804_222243_167424_60B5EAC4 X-CRM114-Status: GOOD ( 24.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024-08-04 17:51, Heiko Stübner wrote: > Am Sonntag, 4. August 2024, 15:59:19 CEST schrieb Dragan Simic: >> On 2024-08-04 15:44, Heiko Stübner wrote: >> > Am Sonntag, 4. August 2024, 15:25:47 CEST schrieb Dragan Simic: >> >> On 2024-08-04 15:20, Yao Zi wrote: >> >> > On Sun, Aug 04, 2024 at 12:05:11PM +0200, Krzysztof Kozlowski wrote: >> >> >> On 03/08/2024 14:55, Yao Zi wrote: >> >> >> > + xin24m: xin24m { >> >> >> >> >> >> Please use name for all fixed clocks which matches current format >> >> >> recommendation: 'clock-([0-9]+|[a-z0-9-]+)+' >> >> > >> >> > Will be fixed in next revision. >> >> >> >> Hmm, why should we apply that rule to the xin24m clock, which is >> >> named exactly like that everywhere else in Rockchip SoC dtsi files? >> >> It's much better to remain consistent. >> > >> > bindings or how we write devicetrees evolve over time ... similarly the >> > xin24m name comes from more than 10 years ago. >> > >> > We also name all those regulator nodes regulator-foo now, which in turn >> > automatically does enforce a nice sorting rule to keep all the >> > regulators >> > around the same area ;-) >> > >> > So I don't see a problem of going with xin24m: clock-xin24m {} >> >> I agree that using "clock-xin24m" makes more sense in general, but the >> trouble is that we can't rename the already existing instances of >> "xin24m", >> because that has become part of the ABI. Thus, I'm not sure that >> breaking >> away from the legacy brings benefits in this particular case. > > In the regulator case, we have _new_ boards using the new _node_-names > but I don't see any renaming of old boards and also don't think we > should. > > But that still does not keep us from using the nicer naming convention > in > new boards ;-) . > > Same with xin24m. We're talking only about the node-name here. The > phandle stays the same and also the actual clock name stays the same > and > really only the actual node name you need to look for in > /proc/device-tree > changes ;-) . > > So I don't see the need to go about changing all the old socs, but new > additions should use improved naming conventions. > > xin24m: clock-xin24m { > compatible = "fixed-clock"; > #clock-cells = <0>; > clock-frequency = <24000000>; > clock-output-names = "xin24m"; > }; Makes sense. Though, updating the dtsi files for older SoCs to follow the new rules, if possible, still remains an itch to me. :)