Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1791120ybe; Tue, 3 Sep 2019 03:36:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqz9klPe6tPk6F8d3eexNd0bhy8JJoB7D/whT777YMJDf132k3DYgmNl8U/tgBQSeZQbSCD6 X-Received: by 2002:a17:902:fe0f:: with SMTP id g15mr11994160plj.2.1567507012982; Tue, 03 Sep 2019 03:36:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567507012; cv=none; d=google.com; s=arc-20160816; b=bzAUw8CHgQyK6QblMCxh4OgMvv5zQ88zOYdvln2v3PTu+oOsKHEyepPmj3MonJFxDd Nqlq3He/ylTPUm5DUyL/7jrg/Bz37UM58j+HoPCdHbn9t6mh41DgaMSGnVdIA4EYZCe7 oeFFXFK6Uv7zgxiwaMtSqG+WsYC6n73OLEB3LWrRzveHEN9CDqRspsJ3/9R9SDIgtCuY q+hQRgZKSlMXrj7YlS9o6ZhDBJNuUTE/qbxvF09Atv7W52gtBPvpIXPsGsS2Sja+DMsb 1MFJLbt1OZoT8V6ftlFTfncfnUwqvzTqLW6dkymYsGQDR3zruvn8OroW/G9JhjZAFmTj 8unQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9N3UY4KZaEhgW2FsDrtvwfrORNGqZ7NcXgaBgp/Avg4=; b=yj5srnGwWhRaY21IMcDQLvWV3Y2wbTgDbFxtz64RFuOX9Ing92JuhNkVyDyqeV+s36 bC+ehEqFVCp1WPzDW+raj2wm3hIRrUb6GDdMlbi11Ih/iwYLNQdjQU6sLbY6/8gMXULk /BMlvnunc45jimeEMS98J/KUOB9Bq9ikekAbXdycNUB2qXG8aV5ziZQoaOQaw3ctjtyG qZwYs2SAYcCbCBLsDjQtmUluGKV+AMHgYcHawQKTejTAC2x6fMTmgVD3+pYr6iCgNxWV kU4zqcDUQUlzLhySAu0mrqVCCM4WaImdQP8TaRncUVDBClt87fnezCmtTP6EfjBerDWI gnRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=P8gMUP3m; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4si14031588pjo.83.2019.09.03.03.36.37; Tue, 03 Sep 2019 03:36:52 -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; dkim=pass header.i=@kernel.org header.s=default header.b=P8gMUP3m; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728678AbfICKe3 (ORCPT + 99 others); Tue, 3 Sep 2019 06:34:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:54898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726936AbfICKe3 (ORCPT ); Tue, 3 Sep 2019 06:34:29 -0400 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 27F5322D6D; Tue, 3 Sep 2019 10:34:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567506868; bh=hptEnLPHuH30TwmUN0YADeJBNKeIbZ4C9q8fPG5LnOI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=P8gMUP3mOTh+x/n5rjAdPdIv3JqWqM7gpfd6mKlV+wayBfTlMzcMwJNo2BTDxXyqa SdHvfzG9+5poUJXXVDEsJ6hlHJAOZfK3c89sD1ALfTf1mk8b12rF4pxNQTLmM4/VsY KLUMd725nc4wCgTfcPx4fqW1nFRqbnBS6pql7pqY= Received: by mail-qk1-f182.google.com with SMTP id s18so4280761qkj.3; Tue, 03 Sep 2019 03:34:28 -0700 (PDT) X-Gm-Message-State: APjAAAUFPP0S4ccnqxcJX+CfPT3ZnirUXuJKsOTKO+UmY/RxOi+ab5Pl SDoH4Hjrvld2jzS4xHSuTeUdayNKwI34slkTFg== X-Received: by 2002:ae9:e212:: with SMTP id c18mr27120739qkc.254.1567506867330; Tue, 03 Sep 2019 03:34:27 -0700 (PDT) MIME-Version: 1.0 References: <20190828124315.48448-1-vadivel.muruganx.ramuthevar@linux.intel.com> <20190828124315.48448-2-vadivel.muruganx.ramuthevar@linux.intel.com> <20190902033716.GA18092@bogus> <9f4d6bdd-072a-ab71-1ef1-1d00c22bd064@linux.intel.com> <39d6fe60-e9f5-d205-ec6c-4a3143fe1e13@linux.intel.com> In-Reply-To: <39d6fe60-e9f5-d205-ec6c-4a3143fe1e13@linux.intel.com> From: Rob Herring Date: Tue, 3 Sep 2019 11:34:16 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] dt-bindings: phy: intel-sdxc-phy: Add YAML schema for LGM SDXC PHY To: "Ramuthevar, Vadivel MuruganX" Cc: Kishon Vijay Abraham I , "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org, Andy Shevchenko , cheol.yong.kim@intel.com, qi-ming.wu@intel.com, peter.harliman.liem@intel.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 3, 2019 at 11:08 AM Ramuthevar, Vadivel MuruganX wrote: > > Hi Rob, > > Thank you so much for prompt reply. > > On 3/9/2019 5:19 PM, Rob Herring wrote: > > On Tue, Sep 3, 2019 at 2:57 AM Ramuthevar, Vadivel MuruganX > > wrote: > >> Hi Rob, > >> > >> Thank you for review comments. > >> > >> On 2/9/2019 9:38 PM, Rob Herring wrote: > >>> On Wed, Aug 28, 2019 at 08:43:14PM +0800, Ramuthevar,Vadivel MuruganX wrote: > >>>> From: Ramuthevar Vadivel Murugan > >>>> > >>>> Add a YAML schema to use the host controller driver with the > >>>> SDXC PHY on Intel's Lightning Mountain SoC. > >>>> > >>>> Signed-off-by: Ramuthevar Vadivel Murugan > >>>> --- > >>>> .../bindings/phy/intel,lgm-sdxc-phy.yaml | 52 ++++++++++++++++++++++ > >>>> .../devicetree/bindings/phy/intel,syscon.yaml | 33 ++++++++++++++ > >>>> 2 files changed, 85 insertions(+) > >>>> create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml > >>>> create mode 100644 Documentation/devicetree/bindings/phy/intel,syscon.yaml > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml > >>>> new file mode 100644 > >>>> index 000000000000..99647207b414 > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml > >>>> @@ -0,0 +1,52 @@ > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>>> +%YAML 1.2 > >>>> +--- > >>>> +$id: http://devicetree.org/schemas/phy/intel,lgm-sdxc-phy.yaml# > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>>> + > >>>> +title: Intel Lightning Mountain(LGM) SDXC PHY Device Tree Bindings > >>>> + > >>>> +maintainers: > >>>> + - Ramuthevar Vadivel Murugan > >>>> + > >>>> +allOf: > >>>> + - $ref: "intel,syscon.yaml" > >>> You don't need this. It should be selected and applied by the compatible > >>> string matching. > >> Agreed, fix it in the next patch. > >>>> + > >>>> +description: Binding for SDXC PHY > >>>> + > >>>> +properties: > >>>> + compatible: > >>>> + const: intel,lgm-sdxc-phy > >>>> + > >>>> + intel,syscon: > >>>> + description: phandle to the sdxc through syscon > >>>> + > >>>> + clocks: > >>>> + maxItems: 1 > >>>> + > >>>> + clock-names: > >>>> + maxItems: 1 > >>>> + > >>>> + "#phy-cells": > >>>> + const: 0 > >>>> + > >>>> +required: > >>>> + - "#phy-cells" > >>>> + - compatible > >>>> + - intel,syscon > >>>> + - clocks > >>>> + - clock-names > >>>> + > >>>> +additionalProperties: false > >>>> + > >>>> +examples: > >>>> + - | > >>>> + sdxc_phy: sdxc_phy { > >>>> + compatible = "intel,lgm-sdxc-phy"; > >>>> + intel,syscon = <&sysconf>; > >>> Make this a child of the below node and then you don't need this. > >>> > >>> If there's a register address range associated with this, then add a reg > >>> property. > >> Thanks for comments, I have defined herewith example > >> > >> sysconf: chiptop@e0020000 { > >> compatible = "intel,syscon"; > > Needs to be SoC specific value. > Agreed! it should be "intel, lgm-syscon" > >> reg = <0xe0020000 0x100>; > >> > >> emmc_phy: emmc_phy { > >> compatible = "intel,lgm-emmc-phy"; > >> intel,syscon = <&sysconf>; > > This is redundant because you can just get the parent node. > > > > If there's a defined register range within the 'intel,syscon' block > > then define it here with 'reg'. > > Agreed!, avoided redundant > > sysconf: chiptop@e0020000 { > compatible = "intel,lgm-syscon"; > emmc_phy: emmc_phy { > compatible = "intel,lgm-emmc-phy"; > reg = <0xe0020000 0x100>; This is the same addresses you had for the parent, so that doesn't seem right. The parent should have the entire range and then the child nodes only the addresses for their functions. However, if the registers are all interleaved then you can really put 'reg' in the child nodes and just have it only in the parent. We don't want to have overlapping addresses in DT. Rob