Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758453AbcDEOoZ (ORCPT ); Tue, 5 Apr 2016 10:44:25 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:36573 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752623AbcDEOoW (ORCPT ); Tue, 5 Apr 2016 10:44:22 -0400 Date: Tue, 5 Apr 2016 16:44:16 +0200 From: Thierry Reding To: Stephen Warren Cc: Kishon Vijay Abraham I , Linus Walleij , Alexandre Courbot , Andrew Bresticker , linux-tegra@vger.kernel.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala Subject: Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support Message-ID: <20160405144416.GA10809@ulmo.ba.sec> References: <1457108379-20794-1-git-send-email-thierry.reding@gmail.com> <1457108379-20794-3-git-send-email-thierry.reding@gmail.com> <56E99F10.1060508@wwwdotorg.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <56E99F10.1060508@wwwdotorg.org> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3306 Lines: 90 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 11:59:44AM -0600, Stephen Warren wrote: > On 03/04/2016 09:19 AM, Thierry Reding wrote: > > From: Thierry Reding > >=20 > > Extend the binding to cover the set of feature found in Tegra210. >=20 > Acked-by: Stephen Warren >=20 > > diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb= -padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-pa= dctl.txt >=20 > > + padctl@0,7009f000 { > ... > > + pads { > ... > > + }; > > + > > + ports { > ... > > + }; >=20 > As a comment not affecting my ack in any way: At the top-level, we place = all > the child nodes into "array container" nodes named "pads" and "ports". Th= is > is nice since it separates different types of child nodes and allows easi= ly > adding more types of child nodes in the future without interference, and = in > a way that allows us to explicitly know what each node is without having = to > interpret its name or compatible value to do so. However, we haven't done > this with the per-lane child nodes inside each pad. If we were to rev the > design, I'd be tempted to suggest: >=20 > padctl@0,7009f000 { > pads { > usb2 { > lanes { // This level is new > usb2-0 { I tried to make this work, but it's unfortunately not possible with the current code. The reason is that the PHY subsystem assumes that either the provider DT node corresponds to that of the device (the usb2 pad in the above example) or one of its children. Hence, putting everything into one more level further down would require some mechanism to tell the subsystem about it so that it can be found. Arguably the current support code isn't a good argument for designing a binding, so perhaps it'd be useful to add this mechanism in order to get a better binding. On the other hand, I'm not sure it's really worth it, since we already have generic bindings that specify the layout of child devices, and those have been agreed upon broadly (presumably). In light of the recent discussion on DPAUX vs. I2C, I see how having the extra level would be useful to provide additional context. If you think it's worth it I can spend the extra time to get this implemented in the core. Thierry --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJXA889AAoJEN0jrNd/PrOhrlwP/1s/hfQKGfeRZJDP4P7W8FRG 7Q6HYYLy3S6Y69EigHnnKdjIDWiIYl/O3UpcxKmA3fGbIzGJzOn2cPvbAPMTnaVr cy0S531prsWOmRSsPk+ev/eLclRJov9Ccsapum0Hp5O7U2FyGFjRKdW1hxh18c/a ewt3hT4NqQgyy4yQ4eTC++RbdbLMd5N/taRDV6T/P9yTrm3Fsf75071qmADgh+2B 5tX1Lofqum+4qEIj8KMJLv+umzj/t+b4eutxQwEsm+v6gAhJamhVdJr0lQ9UZKiH eFyk3UoDHHJBZCeqzoxbHtikVMHk7WzWFA0ZxqYR920Q5CbhAWA89FupDarA6HwO fB79dj8SN6AFxDhOCtggsY2DRrN2kVzBJNUI1OO+a31KNJjuXmpuq5UtXOFgkMtx zWWww8bZvQp6Cysa7RymTanPgTO/ZA0piW0q7kLVebBC7qTQWN/Rs3hVVBjQR/ji 7YrRhcM8aQ/Vdci0SAKqgHog6D3byxThCrVBU/9XsCZceWEh8z/aTvDO2qhFnxDB LBCoxEOURcSttZhx+Wsgn9tOobXZP7KHvwDm1nHdTTHbov5AKUTv5UiO4xIGGu/v MBROApgPAs4vIFlelyVfzxw28F3DwnKUvv5EhWnrFKMPlRBoTdUE3HRWsmw5sgTL K5fQWtSqK2uxE9bl3mn8 =NQmu -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU--