[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5390F5C7.5070301@wwwdotorg.org>
Date: Thu, 05 Jun 2014 16:57:11 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Thierry Reding <thierry.reding@...il.com>
CC: Linus Walleij <linus.walleij@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Andrew Bresticker <abrestic@...omium.org>,
devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] of: Add NVIDIA Tegra XUSB pad controller binding
On 06/05/2014 04:08 PM, Thierry Reding wrote:
> On Thu, Jun 05, 2014 at 10:47:45AM -0600, Stephen Warren wrote:
>> On 06/04/2014 09:16 AM, Thierry Reding wrote:
>>> From: Thierry Reding <treding@...dia.com>
>>>
>>> This patch adds the device tree binding documentation for the XUSB pad
>>> controller found on NVIDIA Tegra SoCs. It exposes both pinmuxing and PHY
>>> capabilities.
>>
>>> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
>>
>>> +- #phy-cells: Should be 1. The specifier is the index of the PHY to reference.
>>> + Possible values are:
>>> + - 0: PCIe
>>> + - 1: SATA
>>
>> Those values are defined in
>> include/dt-bindings/pinctrl/pinctrl-tegra-xusb.h. I personally consider
>> the <dt-bindings/> header files to be part of the binding itself, rather
>> than being derived from the binding. As such, I'd suggest the following
>> changes:
>>
>> * Make this patch 1 not patch 2
>> * Move pinctrl-tegra-xusb.h into this patch.
>> * Remove the list of values above, and replace it with the text "See
>> <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> for the set of valid values".
>
> I remember discussions where people explicitly said that relying on the
> symbolic names in the DT bindings was a mistake because it would mean
> that everyone would need to have access to a mechanism similar to what
> we have in the Linux kernel (and that the header files would always need
> to be shipped with the DT bindings).
The entire point of the headers is so that the binding definitions and
code using them can't get out of sync. In my opinion, the headers *are*
part of the bindings, so of course anyone either reading DT bindings, or
parsing DT, must have the headers, and hence the headers must be bundled
with the DT files or with the bindings wherever they go.
Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)
Powered by blists - more mailing lists