public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Venu Byravarasu <vbyravarasu@nvidia.com>
Cc: kishon <kishon@ti.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"balbi@ti.com" <balbi@ti.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>
Subject: Re: [PATCH 1/7] ARM: tegra: finalize USB EHCI and PHY bindings
Date: Wed, 20 Mar 2013 11:30:15 -0600	[thread overview]
Message-ID: <5149F227.7080702@wwwdotorg.org> (raw)
In-Reply-To: <D958900912E20642BCBC71664EFECE3E6E5092FFE5@BGMAIL02.nvidia.com>

On 03/20/2013 06:15 AM, Venu Byravarasu wrote:
>> -----Original Message-----
>> From: kishon [mailto:kishon@ti.com]
>> Sent: Wednesday, March 20, 2013 4:49 PM
>> To: Venu Byravarasu
>> Cc: gregkh@linuxfoundation.org; stern@rowland.harvard.edu;
>> balbi@ti.com; linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org;
>> swarren@wwwdotorg.org; linux-tegra@vger.kernel.org; devicetree-
>> discuss@lists.ozlabs.org
>> Subject: Re: [PATCH 1/7] ARM: tegra: finalize USB EHCI and PHY bindings
>>
>> Hi,
>>
>> On Monday 18 March 2013 05:59 PM, Venu Byravarasu wrote:
>>> The existing Tegra USB bindings have a few issues:
>>>
>>> 1) Many properties are documented as being part of the EHCI controller
>>> node, yet they apply more to the PHY device. They should be moved.
>>>
>>> 2) Some registers in PHY1 are shared with PHY3, and hence PHY3 needs a
>>> reg entry to point at PHY1's register space. We can't assume the PHY1
>>> driver is present, so the PHY3 driver will directly access those
>>> registers.
>>>
>>> 3) The list of clocks required by the PHY was missing some required
>>> entries.
>>>
>>> This patch fixes the binding definition to resolve these issues.
>>>
>>> Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com>
>>> ---
>>>   .../bindings/usb/nvidia,tegra20-ehci.txt           |   27 +++----------------
>>>   .../bindings/usb/nvidia,tegra20-usb-phy.txt        |   27
>> +++++++++++++++++--
>>>   2 files changed, 29 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
>> b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
>>> index 34c9528..df09330 100644
>>> --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
>>> @@ -6,27 +6,10 @@ Practice : Universal Serial Bus" with the following
>> modifications
>>>   and additions :
>>>
>>>   Required properties :
>>> - - compatible : Should be "nvidia,tegra20-ehci" for USB controllers
>>> -   used in host mode.
>>> - - phy_type : Should be one of "ulpi" or "utmi".
>>>
>>>   Optional properties:
>>> -  - dr_mode : dual role mode. Indicates the working mode for
> 
>>> index 6bdaba2..7ceccd3 100644
>>> --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
>>> +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
>>> @@ -4,8 +4,24 @@ The device node for Tegra SOC USB PHY:
>>>
>>>   Required properties :
>>> + - phy_type : Should be one of "utmi", "ulpi" or "hsic".
>>
>> dt property names generally dont have "_".
> 
> Thanks Kishon, for your comments.
> Is it mandatory or optional?
> If it is mandatory, then I might have to change dr_mode as well along with phy_type.

This rule is basically mandatory for *new* property definitions.

However, both phy_type and dr_mode are properties that already exist and
have historical precedence for their naming. So, I don't think we can
change them. In fact, IIRC, someone even posted some patches to provide
a common set of parsing functions for those properties, and I assume
those patches use the existing names with _ in them. The patches aren't
applied yet though, I think.

(Venu, we already discussed this rule downstream)

  reply	other threads:[~2013-03-20 17:30 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-18 12:29 [PATCH 0/7] USB: PHY: Tegra: registering TEGRA USB PHY as platform driver Venu Byravarasu
2013-03-18 12:29 ` [PATCH 1/7] ARM: tegra: finalize USB EHCI and PHY bindings Venu Byravarasu
2013-03-20 11:19   ` kishon
2013-03-20 12:15     ` Venu Byravarasu
2013-03-20 17:30       ` Stephen Warren [this message]
2013-03-18 12:29 ` [PATCH 2/7] ARM: tegra: update device trees for USB binding rework Venu Byravarasu
2013-03-19 19:53   ` Stephen Warren
2013-03-20 12:20     ` Venu Byravarasu
2013-04-03 19:38     ` Stephen Warren
2013-03-20 11:23   ` kishon
2013-03-20 12:17     ` Venu Byravarasu
2013-03-20 12:24       ` Felipe Balbi
2013-03-20 12:30         ` Venu Byravarasu
2013-03-20 17:31     ` Stephen Warren
2013-03-18 12:29 ` [PATCH 3/7] usb: phy: tegra: Get PHY mode using DT Venu Byravarasu
2013-03-19 19:58   ` Stephen Warren
2013-03-20 12:24     ` Venu Byravarasu
2013-03-18 12:29 ` [PATCH 4/7] usb: phy: tegra: Return correct error value provided by clk_get_sys Venu Byravarasu
2013-03-18 12:29 ` [PATCH 5/7] usb: phy: tegra: get ULPI reset GPIO info using DT Venu Byravarasu
2013-03-18 13:01   ` Sergei Shtylyov
2013-03-19  4:12     ` Venu Byravarasu
2013-03-19 20:03   ` Stephen Warren
2013-03-18 12:29 ` [PATCH 6/7] usb: phy: tegra: Add error handling & clean up Venu Byravarasu
2013-03-19 19:25   ` Stephen Warren
2013-03-19 20:10   ` Stephen Warren
2013-04-03 19:34     ` Stephen Warren
2013-03-18 12:29 ` [PATCH 7/7] usb: phy: registering tegra USB PHY as platform driver Venu Byravarasu
2013-03-19 20:21   ` Stephen Warren
2013-03-20 12:43     ` Venu Byravarasu
2013-03-20 17:51       ` Stephen Warren
2013-03-19 19:51 ` [PATCH 0/7] USB: PHY: Tegra: registering TEGRA " Stephen Warren
2013-03-20  5:59   ` Venu Byravarasu
2013-03-20 12:12   ` Venu Byravarasu
2013-03-20 17:36     ` Stephen Warren
2013-03-20 18:52       ` Stephen Warren
2013-04-03 19:47   ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5149F227.7080702@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=balbi@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=vbyravarasu@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox