Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1302918pxb; Wed, 10 Feb 2021 05:28:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJyAVD/4qrt/Fx8DVEOOfndENmrQHxFlLyk6TL9lOnffng45rfYfWmX6WPdiDIoPEfWO7bFx X-Received: by 2002:a17:906:80d9:: with SMTP id a25mr2797645ejx.405.1612963724918; Wed, 10 Feb 2021 05:28:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612963724; cv=none; d=google.com; s=arc-20160816; b=a9I7tvIg1uzlLisctMZdViIPfIbqwz46V8hYOf1mHJhZXTjW/Zt4cZNaxI6FMtkx+W 55d7ujYGSAvzQcBNXCTwdCQRKtX/gpxyEZpARTxWC9xiwB1rSZu2WFSYe7ROM4LcfDAo if+sHqs9azodKV/anN7ldaaXJEEBNDPj7L3uMvgbhrmAHbdtqtrnbPnAFRMKR2vXi0CE AzAGOauFJKsb2cRRcRNdZJwgB/qJYzGh4ZCEhilJvALED5+LzmhHtEAA95ZfOQTWL6VX fK6y7tqHOwd9z6Mz2vQsgLimItnTbGVmFkWuQyEldaLx6j6gY0YuTu9t+/uKPfx5CVrX eX3g== 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=Qbkae6XY7nF+JRYKySs6fWFYR01dWCp9hvuftwHNY5Q=; b=cwFZx6rPitEKZHOnd0WoLv5KAWj5ujfju/ugk1pmI2f7n2E6ALha+p0MZfGvbUu+mH xd5LddX5N6dPcj/OWO+Gkae85b6v79CPHS0FoSKRAZjaOGlEXqyhcbvNUp/SLxz/mRZW c/8jK/ldDI/s+YuZIPhYwkEfwTUG2qpUnwQb+5KhZrhbWUZm605sVoCgqTXTGalonp99 HV57g1MQiGBtYUsJjXHBLS7VM1rt8zuPkW28FVSWN0OfXgTcxXAREjnxQsSYoiPfz03a S6gaw+sy2W0Is+2yV/fuSCC86IS4fnyuTAY7t/vr9vmJv5ra9nPIJVKxL2E+XlQl+5Vq mlXA== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id br15si1309061ejb.696.2021.02.10.05.28.20; Wed, 10 Feb 2021 05:28:44 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230465AbhBJN0N (ORCPT + 99 others); Wed, 10 Feb 2021 08:26:13 -0500 Received: from mail-wr1-f47.google.com ([209.85.221.47]:36145 "EHLO mail-wr1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229818AbhBJN0E (ORCPT ); Wed, 10 Feb 2021 08:26:04 -0500 Received: by mail-wr1-f47.google.com with SMTP id u14so2558110wri.3; Wed, 10 Feb 2021 05:25:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Qbkae6XY7nF+JRYKySs6fWFYR01dWCp9hvuftwHNY5Q=; b=cvDmmuPRiqVga9SU5Iyh0Bt76l43MvISi/t42nUzlUfnW3T87Bouq/LmEv7YsZMncx seWDlifTkLOPxcQJYQ0ldWORPHVeh8/eiWZpdVeH9w2j3yZDpb13bnp90alCyLTd0H/x oIQ8ERHkvwEfO7UF1wuMrV9/Mdqz10+TqehHNDcG9rapEXgg0X321cERMZdC9k5DQ0t3 CuLgGFtcKkqppHNFCTOnmzhwnWBqGAvAonIyVd8UnVftCbhACtMrFEuqcsCWE6OTlpNj G1g9c1z76J8vKc5i8p+1oOd8QNUM/7Ay0Wt7Vv3VHklej214XRjWO0aE+oednxCvAvea 2/lA== X-Gm-Message-State: AOAM532MWgVDfuNo0vWGmfsBW7oAmeDPzba/4589+EisHUuZm4A9p6pE sQKgSolsCJXul1yxuFkc3LE= X-Received: by 2002:adf:80c8:: with SMTP id 66mr3729053wrl.344.1612963521202; Wed, 10 Feb 2021 05:25:21 -0800 (PST) Received: from kozik-lap (adsl-84-226-167-205.adslplus.ch. [84.226.167.205]) by smtp.googlemail.com with ESMTPSA id f14sm2363823wmj.30.2021.02.10.05.25.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Feb 2021 05:25:19 -0800 (PST) Date: Wed, 10 Feb 2021 14:25:18 +0100 From: Krzysztof Kozlowski To: Tony Lindgren 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: <20210210132518.de7eyzrb5p5xycox@kozik-lap> 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=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 10, 2021 at 03:19:46PM +0200, Tony Lindgren wrote: > * 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. You also could add a suffix or prefix ("fixed-clock-0", "clock-ext"). There is no strict requirement and Rob admitted that as-is was good enough. From my point of view, the dt spec mentions "clock" as one of preferred names, so I would stick to it. Anyway, it's not that important. :) Best regards, Krzysztof