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 3C939C433F5 for ; Tue, 26 Apr 2022 18:45:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EtjuLNiih9JJY+c/KJ031xe9oAQDuDlzUL+sFVxfYds=; b=Q1UxK4cTxOnhxI 7uHxE8HE4l2m2OmDP/+H4R2iRb1KHQoEDw0V+Dut81REqBkoL0GiDLgh1ImaTDvnNy87Y0Ehdf3rS 12cjjcnx04rzyksoxQgFh/nwyEqljtQKExL9dxzb3+wJRt4ieFTJerwuWoODJ2fF/qEVH5r+uKlFX iLPdTHl5tmNyS2920QRCrbiU4RW1R+4Yp0vbJuHO1tgMsE9v0dBxCAgilGOHiPNt32lLXsLF7PGD0 rYP6TbJBnBwS6/3JntkkWlkSzoYhxG3/eJN1u4AKKAruzNFgoAFboCDCbhOJqpEGo8Cw6FPud2apM 4Z3Jfk+k4fZ5MAhan4HQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njQAd-00FoUo-Ie; Tue, 26 Apr 2022 18:44:19 +0000 Received: from mail-oi1-f179.google.com ([209.85.167.179]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1njQAZ-00FoSi-DZ for linux-arm-kernel@lists.infradead.org; Tue, 26 Apr 2022 18:44:16 +0000 Received: by mail-oi1-f179.google.com with SMTP id z8so21685513oix.3 for ; Tue, 26 Apr 2022 11:44:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mx8P3gHsjLCx+sknIhuvMfqYptVzGGmIORChHd23uSc=; b=OzNATqXgtjmR532iN+wX5zPZQqHhRVBrhoWxZjZJT9j5clsMRjEYqI6VvPW/ZgEIHn YBjaQGaIGIEHzsAefvScfD/D9yODd23X2VPCvlbW4IxQSIASZ/7/2cYBHlYOmbc1M4xC YM/70UCZ3K42JnIozgpQ18K9YVxXu1ojoBssTqHcSmRIXgtKrj2G2myfkogdSrlonpgO nouA0ADj9SvWvQzkmLm0Z/HB+DcqRQ4VxzIJ//U5CxbVhv0cnXH3RBpyAhe/YxPga0cr tHuPp67YZHPkhYn9OaY5oAxXdF8MdRh2QNRe1032SrdDvj9keYIbw1xsDWt+lt2kTZeL 374A== X-Gm-Message-State: AOAM5337mVLD+N/1MpfDbm/F6yj97L0BEbhnupfJjrGmxp3mA3SQxCho J+JRGfc4s3yg18QgLuBd9w== X-Google-Smtp-Source: ABdhPJxGVx6HmAUiBu/kUnqmIEoBY/yWAcaWyhG1G4W0lFdInZBsLOspIDqniFb2T3g2odMs73GLNQ== X-Received: by 2002:a54:4e92:0:b0:325:224c:8ff7 with SMTP id c18-20020a544e92000000b00325224c8ff7mr5742089oiy.154.1650998652766; Tue, 26 Apr 2022 11:44:12 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id u20-20020a4a9e94000000b003291f6ac4b2sm5937954ook.28.2022.04.26.11.44.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Apr 2022 11:44:12 -0700 (PDT) Received: (nullmailer pid 2332829 invoked by uid 1000); Tue, 26 Apr 2022 18:44:11 -0000 Date: Tue, 26 Apr 2022 13:44:11 -0500 From: Rob Herring To: Marek Vasut Cc: Alexandre Torgue , arnd@arndb.de, Krzysztof Kozlowski , soc@kernel.org, Stephen Boyd , Philipp Zabel , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-kernel@vger.kernel.org, Ahmad Fatoum , etienne.carriere@st.com Subject: Re: [PATCH 2/8] dt-bindings: clock: stm32mp1: describes clocks if "st,stm32mp1-rcc-secure" Message-ID: References: <20220422150952.20587-1-alexandre.torgue@foss.st.com> <20220422150952.20587-3-alexandre.torgue@foss.st.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220426_114415_490288_4084E518 X-CRM114-Status: GOOD ( 27.04 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Apr 25, 2022 at 09:35:13PM +0200, Marek Vasut wrote: > On 4/25/22 21:11, Rob Herring wrote: > > On Fri, Apr 22, 2022 at 06:31:25PM +0200, Marek Vasut wrote: > > > On 4/22/22 17:09, Alexandre Torgue wrote: > > > > In case of "st,stm32mp1-rcc-secure" (stm32mp1 clock driver with RCC > > > > security support hardened), "clocks" and "clock-names" describe oscillators > > > > and are required. > > > > > > > > Signed-off-by: Alexandre Torgue > > > > > > > > diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml > > > > index 7a251264582d..bb0e0b92e907 100644 > > > > --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml > > > > +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml > > > > @@ -58,14 +58,8 @@ properties: > > > > - st,stm32mp1-rcc-secure > > > > - st,stm32mp1-rcc > > > > - const: syscon > > > > - > > > > - clocks: > > > > - description: > > > > - Specifies the external RX clock for ethernet MAC. > > > > - maxItems: 1 > > > > - > > > > - clock-names: > > > > - const: ETH_RX_CLK/ETH_REF_CLK > > > > + clocks: true > > > > + clock-names: true > > > > > > It looks like this should rather be a property than a compatible string -- > > > the compatible string is used by the OS to determine which hardware is > > > represented by a node, but here it is the same hardware in either case, > > > "st,stm32mp1-rcc" and "st,stm32mp1-rcc-secure", it is still the same > > > STM32MP1 RCC block, just configured differently by some bootloader stage. > > > > > > So why not just add one-liner property of the RCC block like ? > > > st,rcc-in-secure-configuration > > > > Because using compatible was already decided. > > I see ... may I ask why compatible is OK in this case even though this is > encoding a policy (secure/non-secure configuration of the same clock IP) > into DT ? I see 'compatible' as an encoding of what is the programming model of the device. Secure vs. non-secure have different models. PCIe hosts vs endpoint mode is a similar case where we mostly have 2 compatibles (but not always). I wouldn't say which way we do things is set in stone, but in this case we already decided something. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel