linux-kernel - Re: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev Ax/Bx

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]

Message-ID: <516E94FA.9060606@compulab.co.il>
Date:	Wed, 17 Apr 2013 15:26:34 +0300
From:	Igor Grinberg <grinberg@...pulab.co.il>
To:	Roger Quadros <rogerq@...com>
CC:	Tony Lindgren <tony@...mide.com>,
	Robert Nelson <robertcnelson@...il.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-omap@...r.kernel.org,
	b-cousson@...com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: omap3-beagle-xm: Add USB Host support for Rev
 Ax/Bx

On 04/17/13 11:38, Roger Quadros wrote:
> On 04/17/2013 10:56 AM, Igor Grinberg wrote:
>> On 04/17/13 04:30, Robert Nelson wrote:
>>> On Tue, Apr 16, 2013 at 7:52 PM, Tony Lindgren <tony@...mide.com> wrote:
>>>> * Roger Quadros <rogerq@...com> [130415 05:44]:
>>>>> On 04/15/2013 03:35 PM, Roger Quadros wrote:
>>>>>> Provide RESET and Power regulators for the USB PHY,
>>>>>> the USB Host port mode and the PHY device.
>>>>>>
>>>>>> Also provide pin multiplexer information for USB host
>>>>>> pins.
>>>>>>
>>>>>> This will not work for Rev Cx boards because of reversed logic
>>>>>> for USB_POWER_Enable.
>>>>>>
>>>>>> CC: Benoît Cousson <b-cousson@...com>
>>>>>> Signed-off-by: Roger Quadros <rogerq@...com>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/omap3-beagle-xm.dts |   62 +++++++++++++++++++++++++++++++++
>>>>>>  1 files changed, 62 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> index 5a31964..d394c51 100644
>>>>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>>>>> @@ -57,6 +57,60 @@
>>>>>>             ti,mcbsp = <&mcbsp2>;
>>>>>>             ti,codec = <&twl_audio>;
>>>>>>     };
>>>>>> +
>>>>>> +   /* HS USB Port 2 RESET */
>>>>>> +   hsusb2_reset: hsusb2_reset_reg {
>>>>>> +           compatible = "regulator-fixed";
>>>>>> +           regulator-name = "hsusb2_reset";
>>>>>> +           regulator-min-microvolt = <3300000>;
>>>>>> +           regulator-max-microvolt = <3300000>;
>>>>>> +           gpio = <&gpio5 19 0>;   /* gpio_147 */
>>>>>> +           startup-delay-us = <70000>;
>>>>>> +           enable-active-high;
>>>>>> +   };
>>>>>> +
>>>>>> +   /* HS USB Port 2 Power */
>>>>>> +   hsusb2_power: hsusb2_power_reg {
>>>>>> +           compatible = "regulator-fixed";
>>>>>> +           regulator-name = "hsusb2_vbus";
>>>>>> +           regulator-min-microvolt = <3300000>;
>>>>>> +           regulator-max-microvolt = <3300000>;
>>>>>> +           gpio = <&twl_gpio 18 0>;        /* GPIO LEDA */
>>>>>> +           startup-delay-us = <70000>;
>>>>>> +           enable-active-high;     /* FIXME: active-low for Rev. C */
>>>>>
>>>>> Benoit & Tony,
>>>>>
>>>>> Any ideas how to tackle the reversed logic for Rev. C boards?
>>>>
>>>> Sounds like we need a shared omap3-beage.dtsi, then omap3-beagle-xm.dts
>>>> and omap3-beagle-rev-c.dts. Then xm and rev-c can both include the
>>>
>>> Bike-sheding, but we might want to make that "omap3-beagle-xmc.dts" as
>>> there is the "rev c" variant of the original beagle...
>>>
>>> It's too bad we can't read the 3 gpio pin states in the device tree
>>> and make a decision.
>>
>> I would recommend to move the detection to the boot loader and
>> adjust the DT blob at run time (in the boot loader).
>> This way, we will not need to deal with all the (sub)revision stuff.
>>
>>
> Moving the detection to bootloader is fine, but modifying the DT at
> runtime would create a debug/maintenance issue. Instead it could just
> pick one of the .DTBs and pass it to kernel.

Like this will not create create any debug/maintenance issues.... ;-)
We have no problem with debug, as all the DT nodes can be seen in
both U-Boot (with fdt commands) and Linux through procfs...

I've just dropped my 2 cents and I don't really insist...

> 
> Since most users will be using rev-c, I think we should keep the original
> file 'omap3-beagle-xm.dts" as it is for rev-c boards.
> I can just create a new dts file for Revisions A and B that will be
> like so.
> 
> +++ b/arch/arm/boot/dts/omap3-beagle-xm-ab.dts
> @@ -0,0 +1,6 @@
> +/include/ "omap3-beagle-xm.dts"
> +
> +/* On Rev A/B USBHOST_PWR_EN is active high */
> +&hsusb2_power {
> +       enable-active-high;
> +};
> 
> Since omap3-beagle and omap3-beagle-xm use different SoC versions and have
> quite many differences, I don't think it is a good idea to create a common
> file between the two.
> 
> cheers,
> -roger
> 

-- 
Regards,
Igor.
--
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/