linux-kernel - Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Jun 2013 05:32:18 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Benoit Cousson <b-cousson@...com>
Cc:	florian.vaussard@...l.ch, Roger Quadros <rogerq@...com>,
	devicetree-discuss@...ts.ozlabs.org, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/4] ARM: dts: omap4-panda: Add USB Host support

* Benoit Cousson <b-cousson@...com> [130619 05:30]:
> On 06/19/2013 07:05 AM, Florian Vaussard wrote:
> >>>>>>>+
> >>>>>>>+    /* HS USB Port 1 RESET */
> >>>>>>>+    hsusb1_reset: hsusb1_reset_reg {
> >>>>>>>+        compatible = "regulator-fixed";
> >>>>>>>+        regulator-name = "hsusb1_reset";
> >>>>>>>+        regulator-min-microvolt = <3300000>;
> >>>>>>>+        regulator-max-microvolt = <3300000>;
> >>>>>>>+        gpio = <&gpio2 30 0>;    /* gpio_62 */
> >>>>>>>+        startup-delay-us = <70000>;
> >>>>>>>+        enable-active-high;
> >>>>>>>+    };
> >>>>>>
> >>>>>>Is this really a regulator? Or just a GPIO line used to reset the
> >>>>>>USB PHY?
> >>>>>
> >>>>>It is in fact a GPIO line used as reset.
> >>>>>>
> >>>>>>If this is the case, I don't think it should be represented as a
> >>>>>>regulator.
> >>>>>
> >>>>>Why not? I think it fits very well in the regulator device model.
> >>>
> >>>I'm not sure fitting very well is the correct term.
> >>>It works, for sure, but it is no different than when we were trying
> >>>to abuse the regulator fmwk to enable the 32k clock in phoenix.
> >>>It is just a hack.

If it's a reset, then yeah it's not a regulator. If the GPIO line is
really used to control the regulator in the external device, then it
makes sense to set it up as a regulator.

> >>The only difference is there is a dedicated framework for clocks.
> >>Since there is nothing specific to
> >>handle reset lines it is left to the driver writer how he wants to
> >>manage it.
> >>
> >
> >There is a proposed binding for gpio-controlled reset lines, but it is
> >not yet merged [1].
> >I guess it can fit most usage patterns, and it can be an interesting
> >move in the future.
> 
> I'm glad to see that I was not the only one thinking that the
> regulator was not the right fmwk to do that :-)
> 
> Thanks for the pointer Florian.

Good to hear about the gpio-controlled reset lines :)
 
> I guess that series should be merged for 3.11? Based on the thread,
> it should to through arm-soc.
> 
> Roger,
> 
> It might be tricky to have dependency on that series, but if this is
> possible, you should try. Otherwise, just keep the existing one,
> adding that a new solution will be available soon as a disclaimer.

We need some solution for v3.11 for omap4 USB on panda so people can
use it with DT.

Regards,

Tony
--
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/