[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51190AD2.3030006@ti.com>
Date: Mon, 11 Feb 2013 17:14:26 +0200
From: Roger Quadros <rogerq@...com>
To: Mark Rutland <mark.rutland@....com>
CC: "tony@...mide.com" <tony@...mide.com>,
"b-cousson@...com" <b-cousson@...com>,
"balbi@...com" <balbi@...com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
"linux@....linux.org.uk" <linux@....linux.org.uk>,
"kishon@...com" <kishon@...com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 01/14] usb: phy: nop: Add device tree support and binding
information
On 02/11/2013 01:40 PM, Mark Rutland wrote:
> Hello,
>
> On Thu, Feb 07, 2013 at 04:02:41PM +0000, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros <rogerq@...com>
>> Acked-by: Felipe Balbi <balbi@...com>
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34 ++++++++++++++++++
>> drivers/usb/otg/nop-usb-xceiv.c | 36 +++++++++++++++----
>> 2 files changed, 62 insertions(+), 8 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> new file mode 100644
>> index 0000000..d7e2726
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -0,0 +1,34 @@
>> +USB NOP PHY
>> +
>> +Required properties:
>> +- compatible: should be usb-nop-xceiv
>
> This might be better as "linux,usb-no-xceiv", given this is a Linux-specific
> 'device'.
>
> Saying that, I'm not sure I understand why this device needs to be instantiated
> from devicetree. As I understand it from looking at the driver, it's purely a
> Linux implementation detail used in the case of autonomous PHYs, and not an
> actual piece of hardware or firmware system. I must admit to being unfamiliar
> with this area of hardware, have I misunderstood somethign here?
The PHY is a physical device and may need resources like power and clock to be functional.
The only reason that driver is named NOP is that many USB controllers know how to talk to
the standard PHYs and don't need any interface/management software.
The PHY driver you are looking at most likely doesn't have the recent changes I wrote to
manage the PHY clock/reset/power. i.e. patches 3, 4 and 5 in the series
https://lkml.org/lkml/2013/1/28/275
Before this, the ehci-omap driver was trying to manage the PHY power and reset, which was
wrong.
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists