Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1298526pxb; Wed, 10 Feb 2021 05:21:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxpryl5KucoDfx1Z6RDwKA8od255qw3oAODPdADYS6/uNNrE0RpA+rsvoys/+DLLXtmeoz7 X-Received: by 2002:a05:6402:1589:: with SMTP id c9mr3207501edv.282.1612963316780; Wed, 10 Feb 2021 05:21:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612963316; cv=none; d=google.com; s=arc-20160816; b=YIByHCOubHYqhfNQtO/ejHVkWTCU3pKS3nKoxGC7G0Y9cI8z4bQMaxB2nx5dPhlbBc Xq8EYG+K7lR9JhrTYZ1FwlzyBl55+6E5MbIr0u+j+W4HRmshgt2Ko12cIKfqsWqBemNq hHo+KQCmA1gTvacwglqRbU5roV3Isdu20EB5KEErNbROfK9uvHGOYCGNIBtQYLY3ItDz MX/imHMIC7U2bCS3XJH+jxoULmM9+5olu+SO6McrJmcGdIJeB73t4ATTa+58kmOrzuOr Tnn/bZZ1GWKdaUPe/nq6DdzKeclt8hu5phx7iOgHXprDyEdwWNdFTtB4qvczHYA7n44R J2+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=58DKNhKeZ1W+z6Isw0TbK9JYYWOJXVb92041ImLTm/Y=; b=bDTGX3fgE6AD+YfDEzDlayio9Qg1F4ZSEaWWX52RsLSGn8dAwD0IXNx6JNV80kiqVR T5GqFRSRLjL/lSKhy0Q865/QBgX+124DOxdEOy6fBnOFAQrKAOqPXai5qOZSGXT9pcQj B01jtJH4itFg0VqW3H2ZSNa3fsP8gb1Wgqgc1E8QQagmH79xqiFV2QQHSBepdx3/xIGv hXrIdtB9aBGSwOsqS/6w+E3nY17+c2Akaf4RPgXwUqwQjsUAcAi7hEB+6yfNtq8VuW5A DTor3lJ9vu8Y0SuT+zg2DFJNoWSM5dZFOiHAMfVeX1sfslsF+MNbmjl4Wemwt8QB4JFU bznA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q17si1341668edg.401.2021.02.10.05.21.30; Wed, 10 Feb 2021 05:21:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230491AbhBJNUl (ORCPT + 99 others); Wed, 10 Feb 2021 08:20:41 -0500 Received: from muru.com ([72.249.23.125]:59894 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230201AbhBJNUc (ORCPT ); Wed, 10 Feb 2021 08:20:32 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 9040A80EB; Wed, 10 Feb 2021 13:20:07 +0000 (UTC) Date: Wed, 10 Feb 2021 15:19:46 +0200 From: Tony Lindgren To: Krzysztof Kozlowski Cc: Hector Martin , Arnd Bergmann , devicetree@vger.kernel.org, Marc Zyngier , linux-kernel@vger.kernel.org, soc@kernel.org, robh+dt@kernel.org, Olof Johansson , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree Message-ID: References: <20210204203951.52105-1-marcan@marcan.st> <20210204203951.52105-19-marcan@marcan.st> <20210208110441.25qc6yken4effd6c@kozik-lap> <4481998a-27f6-951e-bb4f-a9d2b95f211f@marcan.st> <20210210125548.sdeadc4ncoxu3ikj@kozik-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210210125548.sdeadc4ncoxu3ikj@kozik-lap> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Krzysztof Kozlowski [210210 12:56]: > On Wed, Feb 10, 2021 at 01:34:50PM +0200, Tony Lindgren wrote: > > * Hector Martin [210210 11:14]: > > > On 10/02/2021 19.19, Tony Lindgren wrote: > > > > * Hector Martin 'marcan' [210208 12:05]: > > > > > On 08/02/2021 20.04, Krzysztof Kozlowski wrote: > > > > ... > > > > > > > > > > > + clk24: clk24 { > > > > > > > > > > > > Just "clock". Node names should be generic. > > > > > > > > > > Really? Almost every other device device tree uses unique clock node names. > > > > > > > > Yeah please just use generic node name "clock". FYI, we're still hurting > > > > because of this for the TI clock node names years after because the drivers > > > > got a chance to rely on the clock node name.. > > > > > > > > Using "clock" means your clock driver code won't get a chance to wrongly > > > > use the node name and you avoid similar issues. > > > > > > That means it'll end up like this (so that we can have more than one > > > fixed-clock): > > > > > > clocks { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > > > > clk123: clock@0 { > > > ... > > > reg = <0> > > > } > > > > > > clk456: clock@1 { > > > ... > > > reg = <1> > > > } > > > } > > > > > > Correct? > > > > Yeah, just don't use an imaginary dummy index for the reg. Use a real > > register offset from a clock controller instance base, and a register > > bit offset too if needed. > > No, there is no need for fake "clocks" node with fake addresses. If you > have multiple clocks, the rules are the same as for other similar cases, > e.g. leds: > > { > clock-0 { > ... > }; > > clock-1 { > .. > }; > > soc@0 { > }; > } > > This should not generate any dtc W=1 warnings and work with dtschema > (you need to check for both). OK yeah so no need for the node name there after the "clock-" :) Sounds good to me. Regards, Tony