Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp276284ybl; Fri, 23 Aug 2019 00:19:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqwGcM6lcYBC8ZfpDCN9VkoJy0mOi4cz1CtoMeIYUmDja4o9fJNp1dhF+KSpBJy8kbhrIm9c X-Received: by 2002:a65:62c4:: with SMTP id m4mr2634403pgv.243.1566544752878; Fri, 23 Aug 2019 00:19:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566544752; cv=none; d=google.com; s=arc-20160816; b=Xz/rATJlA5yAZmVQoMuFPs2lnx+JwxGX2V28U2Y4uzcr/NEAUBCKliYjScLmT0ji6S z2b7j0wbdDrg6nR0bKqxXKuVrahEZXEss5FR0zzBnx8AEaa+BHfonknHwp+Vqj1bsooW sUb5GPhkR4scS25FrqRNItkxRM63zQ7d3fLSDVfiK77QyoOqq2GoBsus5LasOoYFiVYd Kk6JtgC0b+86u9K4jb2zOCcG9edVKQYJmVWUqKfB1v/4zCdcMP/PPM3lNaRDbFy2E61s N40I7nyihcXk93htBWF29pvPzOveqM2aiTMd6ZHTRWgrpR0Q7mFYV4LqH6+iBBPzaQU5 PkFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=s6HB5AcPLNfrseCRxHeFz4BAX+NQT3OTvZ8XnWITecU=; b=o5mojR9SNSM5xHvLUrjsAKUfN/SvCmsdgPjorL+ZBoZAmxX0w55w07IdwNn8L4QyAe 2C/cq15eSJU1Ap7HXzEaFeg+c/Jr7uJUgkp1Bx5ma/NwKUJyk8wpaZgI18mULYgRG/ap EpEC3vPVG6Isqfxw+guZoiwT9epWFiCCt0Qc/xzsRmajlIBQIMg9+vIdzmBXp67DMkzF OUin+tfdYQJC6lIWvNrCBxNwJHLirxCn33XGzwhHshIKM0EPtUeDskZuR4usjXlJLD1i g+C521f4F0LfdpI3XZDaOGbQaIOaRLmteUyXCDIijNzM8Acb4hVrKyxSMb1RIQ8ekNUi hA8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m27si1842919pff.186.2019.08.23.00.18.57; Fri, 23 Aug 2019 00:19:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388291AbfHVSXa (ORCPT + 99 others); Thu, 22 Aug 2019 14:23:30 -0400 Received: from gloria.sntech.de ([185.11.138.130]:38588 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727685AbfHVSXa (ORCPT ); Thu, 22 Aug 2019 14:23:30 -0400 Received: from wsip-184-188-36-2.sd.sd.cox.net ([184.188.36.2] helo=phil.localnet) by gloria.sntech.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1i0rjo-0001eW-0S; Thu, 22 Aug 2019 20:23:08 +0200 From: Heiko Stuebner To: Ulf Hansson , "linux-mmc@vger.kernel.org" Cc: Manish Narani , Rob Herring , "mark.rutland@arm.com" , Michal Simek , "adrian.hunter@intel.com" , "christoph.muellner@theobroma-systems.com" , "philipp.tomsich@theobroma-systems.com" , "viresh.kumar@linaro.org" , "scott.branden@broadcom.com" , "ayaka@soulik.info" , "kernel@esmil.dk" , "tony.xie@rock-chips.com" , Rajan Vaja , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-rockchip@lists.infradead.org" Subject: Re: [PATCH v2 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock Date: Thu, 22 Aug 2019 20:23:01 +0200 Message-ID: <4911073.ucheZMAtV3@phil> In-Reply-To: References: <1561958991-21935-1-git-send-email-manish.narani@xilinx.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Donnerstag, 22. August 2019, 15:38:26 CEST schrieb Ulf Hansson: > [...] > > > > > > > --- > > > > > > Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15 > > > ++++++++++- > > > > > ---- > > > > > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > > > > > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > > > > > > index 1edbb04..15c6397 100644 > > > > > > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > > > > > > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt > > > > > > @@ -23,6 +23,10 @@ Required Properties: > > > > > > - reg: From mmc bindings: Register location and length. > > > > > > - clocks: From clock bindings: Handles to clock inputs. > > > > > > - clock-names: From clock bindings: Tuple including "clk_xin" and > > > "clk_ahb" > > > > > > + Apart from these two there is one more optional clock which > > > > > > + is "clk_sdcard". This clock represents output clock from > > > > > > + controller and card. This must be specified when #clock-cells > > > > > > + is specified. > > > > > > - interrupts: Interrupt specifier > > > > > > > > > > > > Required Properties for "arasan,sdhci-5.1": > > > > > > @@ -36,9 +40,10 @@ Optional Properties: > > > > > > - clock-output-names: If specified, this will be the name of the card > > > clock > > > > > > which will be exposed by this device. Required if #clock-cells is > > > > > > specified. > > > > > > - - #clock-cells: If specified this should be the value <0>. With this > > > property > > > > > > - in place we will export a clock representing the Card Clock. This clock > > > > > > - is expected to be consumed by our PHY. You must also specify > > > > > > + - #clock-cells: If specified this should be the value <0>. With this > > > > > > + property in place we will export one clock representing the Card > > > > > > + Clock. This clock is expected to be consumed by our PHY. You must > > > also > > > > > > + specify > > > > > > > > > > specify what? > > > > I think this line was already there, I missed to correct it, Will update in v3. > > > > > > > > > > > > > > The 3rd clock input I assume? This statement means any existing users > > > > > with 2 clock inputs and #clock-cells are in error now. Is that correct? > > > > Yes, this is correct. So far there was only one vendor using '#clock-cells' > > > which is Rockchip. I have sent DT patch (02/11) for that also. > > > > Here this is needed as earlier implementation isn't correct as suggested by > > > Uffe. (https://lkml.org/lkml/2019/6/20/486) . > > > > > > I am not sure how big of a problem the backwards compatible thingy > > > with DT is, in general we must not break it. What do you say Manish? > > > > Though I agree with Uffe on this, there is no other way from my understanding. Please suggest. > > > > > > > > As a workaround, would it be possible to use > > > of_clk_get_from_provider() somehow to address the compatibility issue? > > > > For this to be used we have to parse 'clkspec' from the DT node and pass the same as an argument to this function. In this case also the DT node needs to be updated, which is same as we have done in this series. > > Alright. I guess breaking DTBs for Rockchip platforms isn't > acceptable, especially if those are already widely deployed, which I > have no idea of.... The arasan sdhci is part of the rk3399, so every SBC using that SoC, but also the whole Gru series of ChromeOS devices (Samsung Chromebook Plus among them) would be affected. Heiko