Re: [PATCH] USB: EHCI: fix for leaking isochronous data

[Soeren Moch]

On 14.03.2013 22:33, Alan Stern wrote:

Maybe a better way to go about this is, instead of printing out every
allocation and deallocation, to keep a running counter.  You could have
the driver print out the value of this counter every minute or so.  Any
time the device isn't in use, the counter should be 0.


I implemented the counter. The max value is sampled at the beginning of 
end_free_itds(), the current counter value is sampled at the end of this 
function. Counter values w/o a max number are from the error path in 
itd_urb_transaction().
The number of allocated iTDs can grow to higher values (why?), but 
normally the iTDs are freed during normal operation. Due to some reason 
the number of iTDs suddenly increases until coherent pool exhaustion. 
There is no permanent memory leak, all iTDs are released when the user 
application ends. But imho several thousands of iTDs cannot be the 
intended behavior...


  Soeren


Mar 16 01:12:52 guruvdr kernel: itd_counter:42 (max:174)
Mar 16 01:12:52 guruvdr kernel: itd_counter:0 (max:174)
Mar 16 01:13:13 guruvdr kernel: itd_counter:42 (max:174)
Mar 16 01:13:13 guruvdr kernel: itd_counter:0 (max:174)
Mar 16 01:13:34 guruvdr kernel: itd_counter:87 (max:174)
Mar 16 01:13:34 guruvdr kernel: itd_counter:0 (max:174)
Mar 16 01:13:55 guruvdr kernel: itd_counter:42 (max:426)
Mar 16 01:13:55 guruvdr kernel: itd_counter:0 (max:426)
Mar 16 01:15:14 guruvdr kernel: itd_counter:249 (max:1441)
Mar 16 01:15:14 guruvdr kernel: itd_counter:0 (max:1441)
[...]
Mar 16 02:03:33 guruvdr kernel: itd_counter:0 (max:1441)
Mar 16 02:04:15 guruvdr kernel: itd_counter:150 (max:1441)
Mar 16 02:04:15 guruvdr kernel: itd_counter:0 (max:1441)
Mar 16 02:04:36 guruvdr kernel: itd_counter:42 (max:1441)
Mar 16 02:04:36 guruvdr kernel: itd_counter:0 (max:1441)
Mar 16 02:04:57 guruvdr kernel: itd_counter:42 (max:1441)
Mar 16 02:04:57 guruvdr kernel: itd_counter:0 (max:1441)
Mar 16 02:05:18 guruvdr kernel: itd_counter:42 (max:1441)
Mar 16 02:05:18 guruvdr kernel: itd_counter:0 (max:1441)
Mar 16 02:05:39 guruvdr kernel: itd_counter:42 (max:1441)
Mar 16 02:05:39 guruvdr kernel: itd_counter:0 (max:1441)
Mar 16 02:06:43 guruvdr kernel: itd_counter:254 (max:1441)
Mar 16 02:07:44 guruvdr kernel: itd_counter:968 (max:1469)
Mar 16 02:08:04 guruvdr kernel: itd_counter:1192 (max:1469)
Mar 16 02:08:46 guruvdr kernel: itd_counter:1812 (max:1854)
Mar 16 02:09:07 guruvdr kernel: itd_counter:2117 (max:2159)
Mar 16 02:09:28 guruvdr kernel: itd_counter:2482 (max:2524)
Mar 16 02:09:49 guruvdr kernel: itd_counter:2791 (max:2833)
Mar 16 02:10:10 guruvdr kernel: itd_counter:3088 (max:3409)
Mar 16 02:10:31 guruvdr kernel: itd_counter:3402 (max:3444)
Mar 16 02:10:52 guruvdr kernel: itd_counter:3689 (max:3731)
Mar 16 02:11:13 guruvdr kernel: itd_counter:3950 (max:4073)
Mar 16 02:11:34 guruvdr kernel: itd_counter:4264 (max:4306)
Mar 16 02:11:55 guruvdr kernel: itd_counter:4525 (max:4567)
Mar 16 02:12:16 guruvdr kernel: itd_counter:4803 (max:4845)
Mar 16 02:12:37 guruvdr kernel: itd_counter:5028 (max:5070)
Mar 16 02:13:19 guruvdr kernel: itd_counter:5549 (max:5843)
Mar 16 02:13:40 guruvdr kernel: itd_counter:5836 (max:5878)
Mar 16 02:14:01 guruvdr kernel: itd_counter:6133 (max:6238)
Mar 16 02:14:06 guruvdr kernel: ERROR: 1024 KiB atomic DMA coherent pool 
is too small!
Mar 16 02:14:06 guruvdr kernel: Please increase it with coherent_pool= 
kernel parameter!

Mar 16 02:14:06 guruvdr kernel: itd_counter:6275
Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:06 guruvdr kernel: itd_counter:6275
Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:06 guruvdr kernel: itd_counter:6275
Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:06 guruvdr kernel: itd_counter:6275
Mar 16 02:14:06 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:07 guruvdr kernel: itd_counter:6275
Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:07 guruvdr kernel: itd_counter:6275
Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:07 guruvdr kernel: itd_counter:6275
Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:07 guruvdr kernel: itd_counter:6275
Mar 16 02:14:07 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:08 guruvdr kernel: itd_counter:6275
Mar 16 02:14:08 guruvdr kernel: orion-ehci orion-ehci.0: can't init itds
Mar 16 02:14:08 guruvdr kernel: itd_counter:78 (max:6275)
Mar 16 02:14:22 guruvdr kernel: itd_counter:0 (max:6275)

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Greg Kroah-Hartman]

On Fri, Mar 15, 2013 at 09:13:52PM +, Arnd Bergmann wrote:
> On Friday 15 March 2013, Greg Kroah-Hartman wrote:
> > > Unless something is changed, this patch won't get into 3.9-final.  
> > > Do you want Greg to move it to his usb-linus branch?
> > 
> > It's a bit too "big" for 3.9-final, sorry.
> 
> Would you consider the hot fix at the start of this thread for 3.9
> then? I can resubmit it as a patch for inclusion with the missing
> hunk added in if there are no objections.

Feel free to resend, but remember, I am _very_ leery of pushing this
type of patch in at the moment, given my past history with it...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Sergei Shtylyov]

Hello.

On 03/16/2013 12:11 AM, Arnd Bergmann wrote:


On Friday 15 March 2013, Sergei Shtylyov wrote:

a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
 for generic bus glue" patch on top after it has been tested

 Arnd, sorry, where can I find this patch? Archive search doesn't
turn up anything...

It's in this email thread, in one of my earlier replies to Alan.


   Ah, found it now. I thought however that it already handles the DT 
properties for the EHCI platform data.

Of course, that can be added later...

WBR, Sergei


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Greg Kroah-Hartman wrote:
> > Unless something is changed, this patch won't get into 3.9-final.  
> > Do you want Greg to move it to his usb-linus branch?
> 
> It's a bit too "big" for 3.9-final, sorry.

Would you consider the hot fix at the start of this thread for 3.9
then? I can resubmit it as a patch for inclusion with the missing
hunk added in if there are no objections.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Sergei Shtylyov wrote:
> >
> > a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
> > for generic bus glue" patch on top after it has been tested
> 
> Arnd, sorry, where can I find this patch? Archive search doesn't 
> turn up anything...

It's in this email thread, in one of my earlier replies to Alan. Since
Greg already said that he won't take Roger's patch for 3.9, taking
this one would be pointless as well. I can resubmit it for 3.10
once we know what to do about my hot-fix.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/9] usb: host: ehci-tegra: fix PHY error handling

[Stephen Warren]

On 03/15/2013 03:12 AM, Felipe Balbi wrote:
> PHY layer no longer returns NULL, we must
> switch from IS_ERR_OR_NULL() to IS_ERR().

This change will definitely conflict with some Tegra EHCI/USB-PHY
changes that Venu plans to submit very soon, for 3.10. This is relevant
since we'd previously discussed you ack'ing Venu's patches, and my
applying them to the Tegra tree, due to dependencies between the Tegra
device tree files and his USB changes.

To resolve this, we can do the following:

1) I will create a tiny topic branch containing just the Tegra DT
changes that must happen before the USB driver changes. This can be
based on v3.9-rc1 or similar, and be entirely self-contained.

2) You can merge that topic branch into your USB tree, so that the
changes are present there.

3) I will merge that topic branch into the Tegra tree.

(2) and (3) are both needed so that the exact same commit ID is present
in each of our branches. It's needed in yours as a pre-cursor to Venu's
changes. It's needed in Tegra's because I still hope to activate usage
of the C pre-processor on the Tegra DT files, and that needs to build on
top of the same DT change of Venu's that you also need.

4) Once you've done that, you can take Venu's USB patches through your
USB tree rather than my applying them to the Tegra tree. This will allow
you to resolve any conflicts between your changes and Venu's changes
entirely within your branch simply by applying the patches one after the
other. Nice and simple, and just like any other USB change.

However, this goes against your statement that you "don't accept pull
requests". Perhaps you can make an exception for this case?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Sergei Shtylyov]

Hello.

On 03/15/2013 11:15 PM, Arnd Bergmann wrote:


On Friday 15 March 2013, Alan Stern wrote:

I just got an automated message from Greg:

--
This is a note to let you know that I've just added the patch titled

 USB: EHCI: split ehci-omap out to a separate driver

to my usb git tree which can be found at
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
--

Unless something is changed, this patch won't get into 3.9-final.
Do you want Greg to move it to his usb-linus branch?

I don't care much which way we do it, but I'd certainly like to
see one of these two solutions for the bug:

a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
for generic bus glue" patch on top after it has been tested


   Arnd, sorry, where can I find this patch? Archive search doesn't 
turn up anything...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Two remain problems at chipidea driver

[Svetoslav Neykov]

Hi Peter,

>> There is a core on mips which doesn't support otg. From my point of
>> view, support for dual_role should be a separate patch, ideally by
>> Svetoslav (Cc'ed) who has this hardware, after we've cleaned up all
>> dr-mode related stuff.
>
>What means support OTG? The spec said it or there is a port
>DCCPARAMS_DC =1 but DCCPARAMS_HC = 0?
>
>From my point, I still think if DCCPARAMS_DC = 1, it is save to
>read OTGSC.

>From the mailing list I see you already figured it out already. In my
instance (AR9331 SoC) both DCCPARAMS_HC = 1 and DCCPARAMS_DC = 1. Even
though the chipidea controller supports both modes, the implementation in
the SoC doesn't map the OTGSC register in the address space. This makes it
impossible to detect OTG support by relying on the register content only and
the platform code needs to override the default behavior through dr_mode.
Just for information the host/device mode on this platform can only be
selected at boot, no switch is possible at runtime.

Best regards,
Svetoslav.




--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] usb: phy: cleanups to Kconfig and directories

[Stephen Warren]

On 03/14/2013 05:01 AM, Felipe Balbi wrote:
> On Fri, Mar 08, 2013 at 11:37:17AM -0700, Stephen Warren wrote:
>> On 03/08/2013 11:26 AM, Felipe Balbi wrote:
>>> On Fri, Mar 08, 2013 at 10:14:11AM -0700, Stephen Warren
>>> wrote:
 On 03/08/2013 12:14 AM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Mar 07, 2013 at 02:20:36PM -0700, Stephen Warren 
> wrote:
>> On 03/07/2013 02:35 AM, Felipe Balbi wrote:
>>> Hi folks,
>>> 
>>> inspired by Paul's DWC2 patchset which added 
>>> usb_otg_state_string() (a copy of otg_state_string())
>>> I have now renamed otg_state_string() to 
>>> usb_otg_state_string(), moved it to usb-common, then
>>> moved all phy drivers to drivers/usb/phy/ and
>>> completely deleted the otg directory.
>>> 
>>> We're also removing CONFIG_USB_OTG_UTILS since that
>>> has lots its meaning long ago.
>>> 
>>> I have compiled all patches with allyes, allno and
>>> allmod configs, but please make sure to test on your
>>> platforms to make sure we're not leaking any more
>>> problems to mainline.
>> 
>> What branch do the patches apply to? They didn't "git am"
>> for me on either next-20130305, nor 
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>>  next.
> 
> they're on top of my testing branch.
 
 Ah, thanks. I took that whole branch, built ARM's 
 tegra_defconfig, and see:
 
> warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC) selects 
> USB_ULPI which has unmet direct dependencies (USB_SUPPORT
> && USB_PHY && ARM) warning: (ARCH_TEGRA_2x_SOC && 
> ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT which has
> unmet direct dependencies (USB_SUPPORT && USB_PHY &&
> USB_ULPI) warning: (ARCH_TEGRA_2x_SOC && ARCH_TEGRA_3x_SOC)
> selects USB_ULPI which has unmet direct dependencies
> (USB_SUPPORT && USB_PHY && ARM) warning: (ARCH_TEGRA_2x_SOC
> && ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT which has
> unmet direct dependencies (USB_SUPPORT && USB_PHY &&
> USB_ULPI)
 
 Manually enabling USB_PHY fixes this. However, this
 highlights an issue with your removal of all selects (as
 mentioned in your other email) - it will break perhaps any
 defconfig that has USB enabled.
 
 After enabling USB_PHY, the code builds and runs without
 issue.
>>> 
>>> fair enough, but then I'm just exposing the trouble. ARCH 
>>> shouldn't select USB_ULTI or any of the phy drivers, for that 
>>> matter.
>> 
>> Yes, I think it should instead work like:
>> 
>> ARCH_TEGRA* selects nothing in particular related to USB.
>> 
>> The Tegra EHCI controller Kconfig depends on ARCH_TEGRA so it
>> doesn't show up for other builds. I hope it's OK for the EHCI
>> controller to select USB_ARCH_HAS_EHCI?
> 
> that's something the ARCH should select but it has very little
> value. I guess there has been some discussions about dropping that
> and I support it.
> 
>> The Tegra EHCI controller Kconfig selects everything needed for
>> it to be useful, i.e. PHY support and the Tegra PHY, and I guess
>> the ULPI viewport options.
> 
> should it ? I don't know... There's no way to select something as 
> module, but there's no eas\(y\|ier\) way to make sure PHY is
> enabled when building EHCI-tegra.
> 
>> The Tegra PHY Kconfig probably shouldn't be user-visible (relying
>> on being selected by the Tegra EHCI controller) and itself
>> selects anything it relies on.
> 
> That I really don't like. I think the driver should be selectable
> and build in anything architecture. That's the easier way to:
> 
> a) build test a driver when applying patches; and b) make sure
> drivers won't include  or .

Venu, can you please look into the right changes to make for Tegra,
and drive this forward. Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Alan Stern wrote:
> I just got an automated message from Greg:
> 
> --
> This is a note to let you know that I've just added the patch titled
> 
> USB: EHCI: split ehci-omap out to a separate driver
> 
> to my usb git tree which can be found at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> in the usb-next branch.
> --
> 
> Unless something is changed, this patch won't get into 3.9-final.  
> Do you want Greg to move it to his usb-linus branch?

I don't care much which way we do it, but I'd certainly like to
see one of these two solutions for the bug:

a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support
   for generic bus glue" patch on top after it has been tested
b) Apply my "USB: EHCI: hot-fix OMAP and Orion multiplatform config"
   when I send a version based on the proper tree for 3.9, and leave
   the other ones to do it properly for 3.10.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Alan Stern wrote:
> On Fri, 15 Mar 2013, Arnd Bergmann wrote:
> > @@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device 
> > *dev)
> > return -ENXIO;
> > }
> >  
> > -   if (pdata->power_on) {
> > +   if (pdata && pdata->power_on) {
> > err = pdata->power_on(dev);
> > if (err < 0)
> > return err;
> > }
> 
> Instead of adding these tests for non-NULL pdata all over the place, 
> you could define a static structure with default settings and store a 
> pointer to it if pdata wasn't set initially.

Yes, good idea. Here is a new version. Maybe Alexey or Tony can verify if
that works for them on wm8850. That should be independent of the decision
into which kernel to merge this patch.

Arnd

8<--
>From 016f7ecd1bce61c18d621acf746776491cc8487e Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Fri, 15 Feb 2013 23:12:28 +0100
Subject: [PATCH] USB: EHCI: DT support for generic bus glue

This lets us use the ehci-generic driver on platforms without special
requirements for their ehci controllers. In particular, this is true
for the vt8500/wm8x50 platforms, which currently have a separate
driver that causes problems with multiplatform configurations.

Signed-off-by: Arnd Bergmann 
Cc: Tony Prisk 
Cc: Alexey Charkov 
Cc: Alan Stern 
---
 drivers/usb/host/ehci-hcd.c  |   5 --
 drivers/usb/host/ehci-platform.c |  25 +++--
 drivers/usb/host/ehci-vt8500.c   | 150 ---
 3 files changed, 19 insertions(+), 161 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c750d71..9dfcef6 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1292,11 +1292,6 @@ MODULE_LICENSE ("GPL");
 #define PLATFORM_DRIVERehci_octeon_driver
 #endif
 
-#ifdef CONFIG_ARCH_VT8500
-#include "ehci-vt8500.c"
-#definePLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
 #ifdef CONFIG_PLAT_SPEAR
 #include "ehci-spear.c"
 #define PLATFORM_DRIVERspear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..eaf 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
  *
  * Licensed under the GNU/GPL. See COPYING for details.
  */
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -62,22 +64,26 @@ static const struct ehci_driver_overrides 
platform_overrides __initdata = {
.reset =ehci_platform_reset,
 };
 
+static struct usb_ehci_pdata ehci_platform_defaults;
+
 static int ehci_platform_probe(struct platform_device *dev)
 {
struct usb_hcd *hcd;
struct resource *res_mem;
-   struct usb_ehci_pdata *pdata = dev->dev.platform_data;
+   struct usb_ehci_pdata *pdata;
int irq;
int err = -ENOMEM;
 
-   if (!pdata) {
-   WARN_ON(1);
-   return -ENODEV;
-   }
-
if (usb_disabled())
return -ENODEV;
 
+   if (!dev->dev.platform_data) {
+   dev->dev.platform_data = &ehci_platform_defaults;
+   dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+   dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   }
+   pdata = dev->dev.platform_data;
+
irq = platform_get_irq(dev, 0);
if (irq < 0) {
dev_err(&dev->dev, "no irq provided");
@@ -183,6 +189,12 @@ static int ehci_platform_resume(struct device *dev)
 #define ehci_platform_resume   NULL
 #endif /* CONFIG_PM */
 
+static const struct of_device_id vt8500_ehci_ids[] = {
+   { .compatible = "via,vt8500-ehci", },
+   { .compatible = "wm,prizm-ehci", },
+   {}
+};
+
 static const struct platform_device_id ehci_platform_table[] = {
{ "ehci-platform", 0 },
{ }
@@ -203,6 +215,7 @@ static struct platform_driver ehci_platform_driver = {
.owner  = THIS_MODULE,
.name   = "ehci-platform",
.pm = &ehci_platform_pm_ops,
+   .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
 };
 
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index 7ecf709..000
--- a/drivers/usb/host/ehci-vt8500.c
+++ /dev/null
@@ -1,150 +0,0 @@
-/*
- * drivers/usb/host/ehci-vt8500.c
- *
- * Copyright (C) 2010 Alexey Charkov 
- *
- * Based on ehci-au1xxx.c
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- 

Re: [PATCH 2/5] USB: ftdi_sio: fix use after free in TIOCMIWAIT

[Greg KH]

On Fri, Mar 15, 2013 at 08:29:12PM +0100, Johan Hovold wrote:
> On Fri, Mar 15, 2013 at 12:04:34PM -0700, Greg KH wrote:
> > For now, consider all patches you have sent to me previously, that I
> > have not applied, as dropped from my todo queues.
> 
> Great, but only the USB-ones, right?

Yes, I still have yet to get to the tty ones, but they are still in my
todo queue.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/6] TTY: port hangup and close fixes

[Johan Hovold]

On Fri, Mar 15, 2013 at 12:05:58PM -0700, Greg KH wrote:
> On Thu, Mar 07, 2013 at 03:55:47PM +0100, Johan Hovold wrote:
> > These patches against 3.9-rc1 fix a few issues with tty-port hangup and
> > close.
> 
> Are these for 3.9-final?

I'd say it can wait for 3.10 as it fixes long-standing issues without
any really severe consequences: DTR is being raised or dropped when it
shouldn't, some possibly annoying delays when open fails, and the
callbacks after disconnect that we get in usb-serial that we are already
work around.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB: ftdi_sio: fix use after free in TIOCMIWAIT

[Johan Hovold]

On Fri, Mar 15, 2013 at 12:04:34PM -0700, Greg KH wrote:
> On Fri, Mar 15, 2013 at 06:16:07PM +0100, Johan Hovold wrote:
> > On Wed, Feb 27, 2013 at 01:52:27PM +0100, Johan Hovold wrote:
> > > Make sure to check the serial disconnected flag before accessing port
> > > private data after waking up.
> > > 
> > > This fixes a use after free in the ftdi_sio introduced by commit
> > > 876ae50d94b ("USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort
> > > of TIOCMIWAIT when the device is removed").
> > > 
> > > When switching to tty ports, some lifetime assumptions where changed.
> > > Specifically, close can now be called before the final tty reference is
> > > dropped as part of hangup at device disconnect. Even with the ftdi
> > > private-data refcounting this means that the port private data can be
> > > freed while a process is sleeping on modem-status changes and thus
> > > cannot be relied on to detect disconnects when woken up.
> > 
> > Greg, those changed life-times introduced a second use after free here
> > as well: the wait queue itself. This affects all usb-serial drivers with
> > private wait queues.
> > 
> > My third series with the TIOCMIWAIT-rework fixes this problem, but
> > I'll submit something that can more easily be backported to stable
> > first.
> > 
> > Can you hold back this patch and the two follow up series (or if you
> > prefer all three of my USB-series) and I'll respin and resubmit them
> > shortly?
> 
> Ok, I'm totally confused :)

Yeah, sorry about that. :)

> Care to resend me what you want to have applied to 3.9-final as one
> series, and then, anything you want to have for 3.10, as a separate
> series?  The second one can be "on top" of the first one, if you need it
> to be.

Will do.

> For now, consider all patches you have sent to me previously, that I
> have not applied, as dropped from my todo queues.

Great, but only the USB-ones, right?

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Greg Kroah-Hartman]

On Fri, Mar 15, 2013 at 03:19:08PM -0400, Alan Stern wrote:
> On Fri, 15 Mar 2013, Arnd Bergmann wrote:
> 
> > On Friday 15 March 2013, Alan Stern wrote:
> > > Roger just submitted my patch to split out ehci-omap.
> > 
> > Ok, if we can merge that for 3.9, the main issue will be resolved, because
> > an OMAP+Orion config is much more interesting in practice than adding
> > VT8500 to the mix.
> 
> I just got an automated message from Greg:
> 
> --
> This is a note to let you know that I've just added the patch titled
> 
> USB: EHCI: split ehci-omap out to a separate driver
> 
> to my usb git tree which can be found at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
> in the usb-next branch.
> --
> 
> Unless something is changed, this patch won't get into 3.9-final.  
> Do you want Greg to move it to his usb-linus branch?

It's a bit too "big" for 3.9-final, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Gene Heskett]

On Friday 15 March 2013 15:19:17 Greg KH did opine:

> On Fri, Mar 15, 2013 at 02:39:57PM -0400, Gene Heskett wrote:
> > On Friday 15 March 2013 14:39:35 Greg KH did opine:
> > > On Fri, Mar 15, 2013 at 02:07:52PM -0400, Gene Heskett wrote:
> > > > On Friday 15 March 2013 13:51:47 Greg KH did opine:
> > > > > On Fri, Mar 15, 2013 at 01:20:41PM -0400, Gene Heskett wrote:
> > > > > > Greetings;
> > > > > > 
> > > > > > What modules do I need to make builtin in order to have a
> > > > > > working keyboard
> > > > > 
> > > > > > when the boot fails when the keyboard/mouse is this:
> > > > > What is different from a working system?  Did 3.8.1 work?  Does
> > > > > 3.8.3 work?  We need something to go on here.
> > > > > 
> > > > > greg k-h
> > > > 
> > > > I thought maybe the vendorid etc might be enough.  Sorry.
> > > > 
> > > > No clue what diffs exist at this point Greg, it doesn't get far
> > > > enough to make any log entries for comparisons, and the last
> > > > kernel on this linuxcnc special install of Ubuntu-10.04-4 LTS
> > > > uses a
> > > > 2.6.32-122-43-rtai patched kernel version.  That's what is running
> > > > ATM.
> > > 
> > > That's a huge jump to go from.
> > > 
> > > > I have not built a kernel.org kernel in about 18 months on this
> > > > install but figured since this LTS is going away, I oughty to
> > > > stick an oar back in this water.
> > > > 
> > > > It fails, according to what I see on screen, and I can supply a
> > > > pix of the fail, apparently while mounting disk drives, getting
> > > > to one that doesn't exist, but then stops and falls out 30 secs
> > > > later to a busybox shell prompt with no keyboard or mouse, so a
> > > > tap on the reset is needed.  This same keyboard works well when
> > > > trolling through the grub screen before the boot. The pix is
> > > > still in the camera, but its near 2 megs of raw jpg.  Pastebin
> > > > it?
> > > 
> > > Sure.  But this doesn't sound like a USB problem, does it?  It
> > > sounds like you just don't have the kernel configuration correct
> > > for this system.  Or the fact that your old userspace can not boot
> > > a new kernel, which, odds are, is the problem here.  Please try
> > > upgrading your userspace first before blaming the kernel.
> > > 
> > > good luck,
> > > 
> > > greg k-h
> > 
> > http://imagebin.org/250405
> 
> You seem to be ignoring the last line printed out there, why do you
> think that this is a USB error because the root disk can't be found?
> 
> Odds are you aren't building in the correct disk driver, or, you need to
> fix up your initramfs to point to the correct block device.  None of
> which is a USB error, sorry.
> 
> greg k-h

I might have found it, SATA_NV was a module.  ASUS M2N-SLI Deluxe board 
uses lots of nvidia stuff.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

I don't care for the Sugar Smacks commercial.  I don't like the idea of
a frog jumping on my Breakfast.
-- Lowell, Chicago Reader 10/15/82
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> On Friday 15 March 2013, Alan Stern wrote:
> > Roger just submitted my patch to split out ehci-omap.
> 
> Ok, if we can merge that for 3.9, the main issue will be resolved, because
> an OMAP+Orion config is much more interesting in practice than adding
> VT8500 to the mix.

I just got an automated message from Greg:

--
This is a note to let you know that I've just added the patch titled

USB: EHCI: split ehci-omap out to a separate driver

to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
--

Unless something is changed, this patch won't get into 3.9-final.  
Do you want Greg to move it to his usb-linus branch?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina  wrote:

> Just a datapoint -- I have put a trivial debugging patch in place, and it
> reveals that "nobody cared" for irq 16 happens long after last
>
> I915_WRITE(GMBUS4 + reg_offset, 0);
>
> has been performed in gmbus_wait_hw_status(). On the other hand, if I
> comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
> then it of course falls back to GPIO bit-banging, but the "nobody cared"
> for irq 16 is gone.
>
> So it seems like something gets severely confused by the I915_WRITE to
> GMBUS4 + reg_offset. So far this seems to have been reported solely on
> Lenovos as far as I can see (although a completely different types), so it
> might be some platform-specific quirk?
>
> Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
> 16 at all.

that device is using
i915 :00:02.0: irq 44 for MSI/MSI-X

so can you try to boot with pci=nomsi?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Gene Heskett]

On Friday 15 March 2013 15:02:42 Alan Stern did opine:

> On Fri, 15 Mar 2013, Gene Heskett wrote:
> > On Friday 15 March 2013 14:08:40 Alan Stern did opine:
> > > On Fri, 15 Mar 2013, Gene Heskett wrote:
> > > > Greetings;
> > > > 
> > > > What modules do I need to make builtin in order to have a working
> > > > keyboard
> > > 
> > > > when the boot fails when the keyboard/mouse is this:
> > > The question doesn't make sense.  If boot fails, _none_ of the
> > > devices in the system will work.
> > > 
> > > Alan Stern
> > 
> > The keyboard works during the grub screen session before selecting
> > that freshly built kernel to boot.
> > 
> > It fails while trying to mount a non-existent /dev/sde, and falls out
> > 30 seconds later to a busybox shell prompt, it doesn't make sense
> > that I would have no keyboard then.
> > 
> > I figured you folks should have the path from:
> >  idVendor   0x045e Microsoft Corp.
> >  idProduct  0x0745
> > 
> > to a usable keyboard memorized.
> > 
> > But then I think logically (for a 78 YO)  :)
> 
> You need to have CONFIG_USB, CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD,
> CONFIG_USB_EHCI_HCD, CONFIG_USB_EHCI_PCI, CONFIG_HID, and
> CONFIG_USB_HID all set to y.  Not all of those HCD entries are needed
> -- it depends on your hardware -- but you can include them all anyway.
> 
> Alan Stern

Thanks Alan, I had all those, nother build in progress.  If that bails out, 
I'll just make all the HCD's =yes.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

When you're bored with yourself, marry, and be bored with someone else.
-- David Pryce-Jones
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/6] TTY: port hangup and close fixes

[Greg Kroah-Hartman]

On Thu, Mar 07, 2013 at 03:55:47PM +0100, Johan Hovold wrote:
> These patches against 3.9-rc1 fix a few issues with tty-port hangup and
> close.

Are these for 3.9-final?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB: ftdi_sio: fix use after free in TIOCMIWAIT

[Greg KH]

On Fri, Mar 15, 2013 at 06:16:07PM +0100, Johan Hovold wrote:
> On Wed, Feb 27, 2013 at 01:52:27PM +0100, Johan Hovold wrote:
> > Make sure to check the serial disconnected flag before accessing port
> > private data after waking up.
> > 
> > This fixes a use after free in the ftdi_sio introduced by commit
> > 876ae50d94b ("USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort
> > of TIOCMIWAIT when the device is removed").
> > 
> > When switching to tty ports, some lifetime assumptions where changed.
> > Specifically, close can now be called before the final tty reference is
> > dropped as part of hangup at device disconnect. Even with the ftdi
> > private-data refcounting this means that the port private data can be
> > freed while a process is sleeping on modem-status changes and thus
> > cannot be relied on to detect disconnects when woken up.
> 
> Greg, those changed life-times introduced a second use after free here
> as well: the wait queue itself. This affects all usb-serial drivers with
> private wait queues.
> 
> My third series with the TIOCMIWAIT-rework fixes this problem, but
> I'll submit something that can more easily be backported to stable
> first.
> 
> Can you hold back this patch and the two follow up series (or if you
> prefer all three of my USB-series) and I'll respin and resubmit them
> shortly?

Ok, I'm totally confused :)

Care to resend me what you want to have applied to 3.9-final as one
series, and then, anything you want to have for 3.10, as a separate
series?  The second one can be "on top" of the first one, if you need it
to be.

For now, consider all patches you have sent to me previously, that I
have not applied, as dropped from my todo queues.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Greg KH]

On Fri, Mar 15, 2013 at 02:39:57PM -0400, Gene Heskett wrote:
> On Friday 15 March 2013 14:39:35 Greg KH did opine:
> 
> > On Fri, Mar 15, 2013 at 02:07:52PM -0400, Gene Heskett wrote:
> > > On Friday 15 March 2013 13:51:47 Greg KH did opine:
> > > > On Fri, Mar 15, 2013 at 01:20:41PM -0400, Gene Heskett wrote:
> > > > > Greetings;
> > > > > 
> > > > > What modules do I need to make builtin in order to have a working
> > > > > keyboard
> > > > 
> > > > > when the boot fails when the keyboard/mouse is this:
> > > > What is different from a working system?  Did 3.8.1 work?  Does
> > > > 3.8.3 work?  We need something to go on here.
> > > > 
> > > > greg k-h
> > > 
> > > I thought maybe the vendorid etc might be enough.  Sorry.
> > > 
> > > No clue what diffs exist at this point Greg, it doesn't get far enough
> > > to make any log entries for comparisons, and the last kernel on this
> > > linuxcnc special install of Ubuntu-10.04-4 LTS uses a
> > > 2.6.32-122-43-rtai patched kernel version.  That's what is running
> > > ATM.
> > 
> > That's a huge jump to go from.
> > 
> > > I have not built a kernel.org kernel in about 18 months on this
> > > install but figured since this LTS is going away, I oughty to stick
> > > an oar back in this water.
> > > 
> > > It fails, according to what I see on screen, and I can supply a pix of
> > > the fail, apparently while mounting disk drives, getting to one that
> > > doesn't exist, but then stops and falls out 30 secs later to a
> > > busybox shell prompt with no keyboard or mouse, so a tap on the reset
> > > is needed.  This same keyboard works well when trolling through the
> > > grub screen before the boot. The pix is still in the camera, but its
> > > near 2 megs of raw jpg.  Pastebin it?
> > 
> > Sure.  But this doesn't sound like a USB problem, does it?  It sounds
> > like you just don't have the kernel configuration correct for this
> > system.  Or the fact that your old userspace can not boot a new kernel,
> > which, odds are, is the problem here.  Please try upgrading your
> > userspace first before blaming the kernel.
> > 
> > good luck,
> > 
> > greg k-h
> http://imagebin.org/250405

You seem to be ignoring the last line printed out there, why do you
think that this is a USB error because the root disk can't be found?

Odds are you aren't building in the correct disk driver, or, you need to
fix up your initramfs to point to the correct block device.  None of
which is a USB error, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: EHCI: fix regression during bus resume

[Alan Stern]

This patch (as1663) fixes a regression caused by commit
6e0c3339a6f19d748f16091d0a05adeb1e1f822b (USB: EHCI: unlink one async
QH at a time).  In order to avoid keeping multiple QHs in an unusable
intermediate state, that commit changed unlink_empty_async() so that
it unlinks only one empty QH at a time.

However, when the EHCI root hub is suspended, _all_ async QHs need to
be unlinked.  ehci_bus_suspend() used to do this by calling
unlink_empty_async(), but now this only unlinks one of the QHs, not
all of them.

The symptom is that when the root hub is resumed, USB communications
don't work for some period of time.  This is because ehci-hcd doesn't
realize it needs to restart the async schedule; it assumes that
because some QHs are already on the schedule, the schedule must be
running.

The easiest way to fix the problem is add a new function that unlinks
all the async QHs when the root hub is suspended.

This patch should be applied to all kernels that have the 6e0c3339a6f1
commit.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Adrian Bassett 
CC: 

---

 drivers/usb/host/ehci-hcd.c |1 +
 drivers/usb/host/ehci-hub.c |2 +-
 drivers/usb/host/ehci-q.c   |   13 +
 3 files changed, 15 insertions(+), 1 deletion(-)

Index: usb-3.9/drivers/usb/host/ehci-hcd.c
===
--- usb-3.9.orig/drivers/usb/host/ehci-hcd.c
+++ usb-3.9/drivers/usb/host/ehci-hcd.c
@@ -302,6 +302,7 @@ static void ehci_quiesce (struct ehci_hc
 
 static void end_unlink_async(struct ehci_hcd *ehci);
 static void unlink_empty_async(struct ehci_hcd *ehci);
+static void unlink_empty_async_suspended(struct ehci_hcd *ehci);
 static void ehci_work(struct ehci_hcd *ehci);
 static void start_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
 static void end_unlink_intr(struct ehci_hcd *ehci, struct ehci_qh *qh);
Index: usb-3.9/drivers/usb/host/ehci-hub.c
===
--- usb-3.9.orig/drivers/usb/host/ehci-hub.c
+++ usb-3.9/drivers/usb/host/ehci-hub.c
@@ -328,7 +328,7 @@ static int ehci_bus_suspend (struct usb_
ehci->rh_state = EHCI_RH_SUSPENDED;
 
end_unlink_async(ehci);
-   unlink_empty_async(ehci);
+   unlink_empty_async_suspended(ehci);
ehci_handle_intr_unlinks(ehci);
end_free_itds(ehci);
 
Index: usb-3.9/drivers/usb/host/ehci-q.c
===
--- usb-3.9.orig/drivers/usb/host/ehci-q.c
+++ usb-3.9/drivers/usb/host/ehci-q.c
@@ -1316,6 +1316,19 @@ static void unlink_empty_async(struct eh
}
 }
 
+/* The root hub is suspended; unlink all the async QHs */
+static void unlink_empty_async_suspended(struct ehci_hcd *ehci)
+{
+   struct ehci_qh  *qh;
+
+   while (ehci->async->qh_next.qh) {
+   qh = ehci->async->qh_next.qh;
+   WARN_ON(!list_empty(&qh->qtd_list));
+   single_unlink_async(ehci, qh);
+   }
+   start_iaa_cycle(ehci, false);
+}
+
 /* makes sure the async qh will become idle */
 /* caller must own ehci->lock */
 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Gene Heskett]

On Friday 15 March 2013 14:39:35 Greg KH did opine:

> On Fri, Mar 15, 2013 at 02:07:52PM -0400, Gene Heskett wrote:
> > On Friday 15 March 2013 13:51:47 Greg KH did opine:
> > > On Fri, Mar 15, 2013 at 01:20:41PM -0400, Gene Heskett wrote:
> > > > Greetings;
> > > > 
> > > > What modules do I need to make builtin in order to have a working
> > > > keyboard
> > > 
> > > > when the boot fails when the keyboard/mouse is this:
> > > What is different from a working system?  Did 3.8.1 work?  Does
> > > 3.8.3 work?  We need something to go on here.
> > > 
> > > greg k-h
> > 
> > I thought maybe the vendorid etc might be enough.  Sorry.
> > 
> > No clue what diffs exist at this point Greg, it doesn't get far enough
> > to make any log entries for comparisons, and the last kernel on this
> > linuxcnc special install of Ubuntu-10.04-4 LTS uses a
> > 2.6.32-122-43-rtai patched kernel version.  That's what is running
> > ATM.
> 
> That's a huge jump to go from.
> 
> > I have not built a kernel.org kernel in about 18 months on this
> > install but figured since this LTS is going away, I oughty to stick
> > an oar back in this water.
> > 
> > It fails, according to what I see on screen, and I can supply a pix of
> > the fail, apparently while mounting disk drives, getting to one that
> > doesn't exist, but then stops and falls out 30 secs later to a
> > busybox shell prompt with no keyboard or mouse, so a tap on the reset
> > is needed.  This same keyboard works well when trolling through the
> > grub screen before the boot. The pix is still in the camera, but its
> > near 2 megs of raw jpg.  Pastebin it?
> 
> Sure.  But this doesn't sound like a USB problem, does it?  It sounds
> like you just don't have the kernel configuration correct for this
> system.  Or the fact that your old userspace can not boot a new kernel,
> which, odds are, is the problem here.  Please try upgrading your
> userspace first before blaming the kernel.
> 
> good luck,
> 
> greg k-h
http://imagebin.org/250405
Thanks Greg

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

The two things that can get you into trouble quicker than anything else
are fast women and slow horses.
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Alan Stern]

On Fri, 15 Mar 2013, Gene Heskett wrote:

> On Friday 15 March 2013 14:08:40 Alan Stern did opine:
> 
> > On Fri, 15 Mar 2013, Gene Heskett wrote:
> > > Greetings;
> > > 
> > > What modules do I need to make builtin in order to have a working
> > > keyboard
> > 
> > > when the boot fails when the keyboard/mouse is this:
> > The question doesn't make sense.  If boot fails, _none_ of the devices
> > in the system will work.
> > 
> > Alan Stern
> 
> The keyboard works during the grub screen session before selecting that 
> freshly built kernel to boot.
> 
> It fails while trying to mount a non-existent /dev/sde, and falls out 30 
> seconds later to a busybox shell prompt, it doesn't make sense that I would 
> have no keyboard then.
> 
> I figured you folks should have the path from:
>  idVendor   0x045e Microsoft Corp.
>  idProduct  0x0745 
> 
> to a usable keyboard memorized.
> 
> But then I think logically (for a 78 YO)  :)

You need to have CONFIG_USB, CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD, 
CONFIG_USB_EHCI_HCD, CONFIG_USB_EHCI_PCI, CONFIG_HID, and 
CONFIG_USB_HID all set to y.  Not all of those HCD entries are needed 
-- it depends on your hardware -- but you can include them all anyway.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][v3] xhci: correctly enable interrupts

[Greg KH]

On Tue, Mar 05, 2013 at 11:45:28AM +0100, Thomas Renninger wrote:
> On Monday, March 04, 2013 05:14:43 PM Thomas Renninger wrote:
> > From: Hannes Reinecke 
> > 
> > xhci has its own interrupt enabling routine, which will try to
> > use MSI-X/MSI if present. So the usb core shouldn't try to enable
> > legacy interrupts; on some machines the xhci legacy IRQ setting
> > is invalid.
> > 
> > v3: Be careful to not break XHCI_BROKEN_MSI workaround (by trenn)
> > 
> > Cc: Bjorn Helgaas 
> > Cc: Oliver Neukum 
> > Cc: Thomas Renninger 
> > Cc: Yinghai Lu 
> > Cc: Frederik Himpe 
> > Cc: David Haerdeman 
> > Cc: Alan Stern 
> > 
> > Reviewed-by: Thomas Renninger 
> > Signed-off-by: Hannes Reinecke 
> 
> Argh, I should have added:
> CC: sta...@kernel.org

You mean "sta...@vger.kernel.org" :)

I'll go do it...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Gene Heskett]

On Friday 15 March 2013 14:08:40 Alan Stern did opine:

> On Fri, 15 Mar 2013, Gene Heskett wrote:
> > Greetings;
> > 
> > What modules do I need to make builtin in order to have a working
> > keyboard
> 
> > when the boot fails when the keyboard/mouse is this:
> The question doesn't make sense.  If boot fails, _none_ of the devices
> in the system will work.
> 
> Alan Stern

The keyboard works during the grub screen session before selecting that 
freshly built kernel to boot.

It fails while trying to mount a non-existent /dev/sde, and falls out 30 
seconds later to a busybox shell prompt, it doesn't make sense that I would 
have no keyboard then.

I figured you folks should have the path from:
 idVendor   0x045e Microsoft Corp.
 idProduct  0x0745 

to a usable keyboard memorized.

But then I think logically (for a 78 YO)  :)
 
Thanks Alan.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

To be or not to be.
-- Shakespeare
To do is to be.
-- Nietzsche
To be is to do.
-- Sartre
Do be do be do.
-- Sinatra
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Greg KH]

On Fri, Mar 15, 2013 at 02:07:52PM -0400, Gene Heskett wrote:
> On Friday 15 March 2013 13:51:47 Greg KH did opine:
> 
> > On Fri, Mar 15, 2013 at 01:20:41PM -0400, Gene Heskett wrote:
> > > Greetings;
> > > 
> > > What modules do I need to make builtin in order to have a working
> > > keyboard
> > 
> > > when the boot fails when the keyboard/mouse is this:
> > What is different from a working system?  Did 3.8.1 work?  Does 3.8.3
> > work?  We need something to go on here.
> > 
> > greg k-h
> 
> I thought maybe the vendorid etc might be enough.  Sorry.
> 
> No clue what diffs exist at this point Greg, it doesn't get far enough to 
> make any log entries for comparisons, and the last kernel on this linuxcnc 
> special install of Ubuntu-10.04-4 LTS uses a 2.6.32-122-43-rtai patched 
> kernel version.  That's what is running ATM.

That's a huge jump to go from.

> I have not built a kernel.org kernel in about 18 months on this install but 
> figured since this LTS is going away, I oughty to stick an oar back in this 
> water.
> 
> It fails, according to what I see on screen, and I can supply a pix of the 
> fail, apparently while mounting disk drives, getting to one that doesn't 
> exist, but then stops and falls out 30 secs later to a busybox shell prompt 
> with no keyboard or mouse, so a tap on the reset is needed.  This same 
> keyboard works well when trolling through the grub screen before the boot.  
> The pix is still in the camera, but its near 2 megs of raw jpg.  Pastebin 
> it?

Sure.  But this doesn't sound like a USB problem, does it?  It sounds
like you just don't have the kernel configuration correct for this
system.  Or the fact that your old userspace can not boot a new kernel,
which, odds are, is the problem here.  Please try upgrading your
userspace first before blaming the kernel.

good luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Gene Heskett]

On Friday 15 March 2013 13:51:47 Greg KH did opine:

> On Fri, Mar 15, 2013 at 01:20:41PM -0400, Gene Heskett wrote:
> > Greetings;
> > 
> > What modules do I need to make builtin in order to have a working
> > keyboard
> 
> > when the boot fails when the keyboard/mouse is this:
> What is different from a working system?  Did 3.8.1 work?  Does 3.8.3
> work?  We need something to go on here.
> 
> greg k-h

I thought maybe the vendorid etc might be enough.  Sorry.

No clue what diffs exist at this point Greg, it doesn't get far enough to 
make any log entries for comparisons, and the last kernel on this linuxcnc 
special install of Ubuntu-10.04-4 LTS uses a 2.6.32-122-43-rtai patched 
kernel version.  That's what is running ATM.

I have not built a kernel.org kernel in about 18 months on this install but 
figured since this LTS is going away, I oughty to stick an oar back in this 
water.

It fails, according to what I see on screen, and I can supply a pix of the 
fail, apparently while mounting disk drives, getting to one that doesn't 
exist, but then stops and falls out 30 secs later to a busybox shell prompt 
with no keyboard or mouse, so a tap on the reset is needed.  This same 
keyboard works well when trolling through the grub screen before the boot.  
The pix is still in the camera, but its near 2 megs of raw jpg.  Pastebin 
it?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

You will be honored for contributing your time and skill to a worthy cause.
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: net2280: remove leftover driver->unbind call in error pathway

[Alan Stern]

This patch (as1667) removes an incorrect driver->unbind() call from
the net2280 driver.  If startup fails, the UDC core takes care of
unbinding the gadget driver automatically; the controller driver
shouldn't do it too.

Signed-off-by: Alan Stern 

---

 drivers/usb/gadget/net2280.c |1 -
 1 file changed, 1 deletion(-)

Index: usb-3.9/drivers/usb/gadget/net2280.c
===
--- usb-3.9.orig/drivers/usb/gadget/net2280.c
+++ usb-3.9/drivers/usb/gadget/net2280.c
@@ -1924,7 +1924,6 @@ static int net2280_start(struct usb_gadg
 err_func:
device_remove_file (&dev->pdev->dev, &dev_attr_function);
 err_unbind:
-   driver->unbind (&dev->gadget);
dev->gadget.dev.driver = NULL;
dev->driver = NULL;
return retval;

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: UDC core: fix a regression during gadget driver unbinding

[Alan Stern]

This patch (as1666) fixes a regression in the UDC core.  The core
takes care of unbinding gadget drivers, and it does the unbinding
before telling the UDC driver to turn off the controller hardware.
When the call to the udc_stop callback is made, the gadget no longer
has a driver.  The callback routine should not be invoked with a
pointer to the old driver; doing so can cause problems (such as
use-after-free accesses in net2280).

This patch should be applied, with appropriate context changes, to all
the stable kernels going back to 3.1.

Signed-off-by: Alan Stern 
CC: 

---

 drivers/usb/gadget/udc-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: usb-3.9/drivers/usb/gadget/udc-core.c
===
--- usb-3.9.orig/drivers/usb/gadget/udc-core.c
+++ usb-3.9/drivers/usb/gadget/udc-core.c
@@ -216,7 +216,7 @@ static void usb_gadget_remove_driver(str
usb_gadget_disconnect(udc->gadget);
udc->driver->disconnect(udc->gadget);
udc->driver->unbind(udc->gadget);
-   usb_gadget_udc_stop(udc->gadget, udc->driver);
+   usb_gadget_udc_stop(udc->gadget, NULL);
 
udc->driver = NULL;
udc->dev.driver = NULL;

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Alan Stern]

On Fri, 15 Mar 2013, Gene Heskett wrote:

> Greetings;
> 
> What modules do I need to make builtin in order to have a working keyboard 
> when the boot fails when the keyboard/mouse is this:

The question doesn't make sense.  If boot fails, _none_ of the devices
in the system will work.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ccg USB gadget driver is now dead

[Felipe Balbi]

HI,

On Fri, Mar 15, 2013 at 08:11:16AM -0700, Greg KH wrote:
> On Fri, Mar 15, 2013 at 09:37:02AM +0200, Felipe Balbi wrote:
> > On Thu, Mar 14, 2013 at 03:25:05PM -0700, Greg KH wrote:
> > > FYI, I just applied this patch to my staging and USB trees, hopefully
> > > this makes some people here happy.
> > > 
> > > 
> > > 
> > > From: Greg Kroah-Hartman 
> > > Date: Thu, 14 Mar 2013 15:22:40 -0700
> > > Subject: Staging: ccg: remove it from the build
> > > 
> > > This driver has been nothing but trouble, and no one shipping a new
> > > Android device uses it, so let's just drop it, making the USB Gadget
> > > driver authors lives a whole lot easier as they do their rework.
> > > 
> > > Cc: John Stultz 
> > > Cc: Paul Bolle 
> > > Signed-off-by: Greg Kroah-Hartman 
> > 
> > thanks :-)
> > 
> > > ---
> > >  drivers/staging/Kconfig  | 2 --
> > >  drivers/staging/Makefile | 1 -
> > >  2 files changed, 3 deletions(-)
> > 
> > But you forgot to actually delete the files, right ?
> 
> No, I did that in a separate patch in the staging-next tree.  I made
> this a "simple" patch for the USB tree to take as well, so there
> wouldn't be any "you deleted the same file in two different branches"
> confusion.

alright, thanks for the notice ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: Linux USB file storage gadget with new UDC

[Felipe Balbi]

On Fri, Mar 15, 2013 at 11:00:45AM -0400, Alan Stern wrote:
> On Fri, 15 Mar 2013, Felipe Balbi wrote:
> 
> > On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote:
> > > Hi,
> > > 
> > > > On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote:
> > > >> For bulk transfer, the new UDC driver has one problem. When SCSI
> > > >> Inquiry command is received, the UDC driver interrupt routine will
> > > >> receive it first. However, the queue function is not yet called, and
> > > >> queue buffer is not yet added. Thus, interrupt routine is not able to
> > > >> store the SCSI Inquiry command to the queue buffer.
> > > >>
> > > >> This is a serious problem, what is the way to synchronise UDC driver
> > > >> and file storage gadget driver for SCSI command bulk transfer?
> > > >
> > > > don't process the interrupt until you receive a queue. Data will be
> > > > pending in controller's FIFO until then.
> > > >
> > > 
> > > change to do exactly that, bulk transfer interrupt come in, don't
> > > process, then queue function is called to add  queue buffer. After
> > > that, no more bulk transfer interrupt come in.
> > 
> > did you process the pending data from FIFO after queue was called ?
> 
> I'm not sure about the details of how the controller hardware works.  
> But what should happen is this: When the controller receives the bulk 
> packet containing the INQUIRY command, it should send back NAK until it 
> has a buffer ready to store the packet.

right, with all controllers I have seen so far, this means just not
processing the interrupt, AKA not starting a transfer.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> On Friday 15 March 2013, Alan Stern wrote:
> > Roger just submitted my patch to split out ehci-omap.
> 
> Ok, if we can merge that for 3.9, the main issue will be resolved, because
> an OMAP+Orion config is much more interesting in practice than adding
> VT8500 to the mix.

I don't know if the patch will get into 3.9.  That's up to Greg; IIRC 
Roger did not ask for it.

> An alternative for VT8500 would be to remove drivers/usb/host/ehci-vt8500.c
> completely and use the generic ehci-platform.c bus glue with added DT
> support, as the patch below that I just hacked up. Not sure if that
> anyone would prefer that over the hot-fix for 3.9, but it's possibly
> a better solution in the long run.

Getting rid of driver files is always worthwhile.

> @@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device 
> *dev)
>   return -ENXIO;
>   }
>  
> - if (pdata->power_on) {
> + if (pdata && pdata->power_on) {
>   err = pdata->power_on(dev);
>   if (err < 0)
>   return err;
>   }

Instead of adding these tests for non-NULL pdata all over the place, 
you could define a static structure with default settings and store a 
pointer to it if pdata wasn't set initially.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Keyboard/mouse dead in 3.8.2 from kernel.org

[Greg KH]

On Fri, Mar 15, 2013 at 01:20:41PM -0400, Gene Heskett wrote:
> Greetings;
> 
> What modules do I need to make builtin in order to have a working keyboard 
> when the boot fails when the keyboard/mouse is this:

What is different from a working system?  Did 3.8.1 work?  Does 3.8.3
work?  We need something to go on here.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Keyboard/mouse dead in 3.8.2 from kernel.org

[Gene Heskett]

Greetings;

What modules do I need to make builtin in order to have a working keyboard 
when the boot fails when the keyboard/mouse is this:

Bus 002 Device 002: ID 045e:0745 Microsoft Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x045e Microsoft Corp.
  idProduct  0x0745 
  bcdDevice6.63
  iManufacturer   1 Microsoft
  iProduct2 Microsoft� 2.4GHz Transceiver v7.0
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   84
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  57
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval   4
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  2 Mouse
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 295
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.11
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 319
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0020  1x 32 bytes
bInterval   1
Device Status: 0x
  (Bus Powered)

Thanks for any hints.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page:  is up!
My views 

An efficient and a successful administration manifests itself equally in
small as in great matters.
-- W. Churchill
I was taught to respect my elders, but its getting 
harder and harder to find any...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a messa

Re: [PATCH 1/1] usb: xhci: fix build warning

[Sarah Sharp]

On Fri, Mar 15, 2013 at 10:47:50AM -0400, Alan Stern wrote:
> On Fri, 15 Mar 2013, Peter Chen wrote:
> 
> > On Thu, Mar 14, 2013 at 10:59:45AM -0400, Alan Stern wrote:
> > > On Thu, 14 Mar 2013, Peter Chen wrote:
> > > 
> > > > /home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:
> > > >  In function ‘handle_port_status’:
> > > > /home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580:
> > > >  warning: ‘hcd’ may be used uninitialized in this function
> > > > 
> > > > Signed-off-by: Peter Chen 
> > > > ---
> > > >  drivers/usb/host/xhci-ring.c |4 ++--
> > > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > > > index 8828754..17dace0 100644
> > > > --- a/drivers/usb/host/xhci-ring.c
> > > > +++ b/drivers/usb/host/xhci-ring.c
> > > > @@ -1588,6 +1588,8 @@ static void handle_port_status(struct xhci_hcd 
> > > > *xhci,
> > > > __le32 __iomem **port_array;
> > > > bool bogus_port_status = false;
> > > >  
> > > > +   /* Find the right roothub. */
> > > > +   hcd = xhci_to_hcd(xhci);
> > > > /* Port status change events always have a successful 
> > > > completion code */
> > > > if (GET_COMP_CODE(le32_to_cpu(event->generic.field[2])) != 
> > > > COMP_SUCCESS) {
> > > > xhci_warn(xhci, "WARN: xHC returned failed port status 
> > > > event\n");
> > > > @@ -1629,8 +1631,6 @@ static void handle_port_status(struct xhci_hcd 
> > > > *xhci,
> > > >  * into the index into the ports on the correct split roothub, 
> > > > and the
> > > >  * correct bus_state structure.
> > > >  */
> > > > -   /* Find the right roothub. */
> > > > -   hcd = xhci_to_hcd(xhci);
> > > > if ((major_revision == 0x03) != (hcd->speed == HCD_USB3))
> > > > hcd = xhci->shared_hcd;
> > > 
> > > You forgot to move these last two lines along with the first two.
> > 
> > No, major_revision is got above it.
> > 
> > In fact, the old logic is no problem due to flag bogus_port_status.
> 
> This doesn't matter.  Your change makes the code more fragile and
> harder to understand, because in your version "hcd" is initialized in
> two separate places.  The initialization should remain a single block
> of code.
> 
> "Works okay" isn't good enough.  A lot of programmers seem to have
> trouble absorbing this concept.  The code needs to be _clear_, because
> it needs to continue to work correctly after other people make changes.  
> If those other people can't understand it then they are likely to break
> the code.

I agree with Alan.  The code will be more clear if the check for the
shared host controller is moved up.  It especially doesn't make any
sense to move the comment "Find the right roothub" without the following
conditional to actually find the right roothub.

And which compiler/kernel were you building this on?  I don't see this
warning when I compile 3.9-rc1 from Greg's usb-linus branch.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB: ftdi_sio: fix use after free in TIOCMIWAIT

[Johan Hovold]

On Wed, Feb 27, 2013 at 01:52:27PM +0100, Johan Hovold wrote:
> Make sure to check the serial disconnected flag before accessing port
> private data after waking up.
> 
> This fixes a use after free in the ftdi_sio introduced by commit
> 876ae50d94b ("USB: ftdi_sio: fix race condition in TIOCMIWAIT, and abort
> of TIOCMIWAIT when the device is removed").
> 
> When switching to tty ports, some lifetime assumptions where changed.
> Specifically, close can now be called before the final tty reference is
> dropped as part of hangup at device disconnect. Even with the ftdi
> private-data refcounting this means that the port private data can be
> freed while a process is sleeping on modem-status changes and thus
> cannot be relied on to detect disconnects when woken up.

Greg, those changed life-times introduced a second use after free here
as well: the wait queue itself. This affects all usb-serial drivers with
private wait queues.

My third series with the TIOCMIWAIT-rework fixes this problem, but
I'll submit something that can more easily be backported to stable
first.

Can you hold back this patch and the two follow up series (or if you
prefer all three of my USB-series) and I'll respin and resubmit them
shortly?

Thanks,
Johan


> Cc: stable 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/ftdi_sio.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index edd162d..83dd0b9 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -71,7 +71,6 @@ struct ftdi_private {
>   struct async_icount icount;
>   wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
>   char prev_status;/* Used for TIOCMIWAIT */
> - bool dev_gone;/* Used to abort TIOCMIWAIT */
>   char transmit_empty;/* If transmitter is empty or not */
>   __u16 interface;/* FT2232C, FT2232H or FT4232H port interface
>  (0 for FT232/245) */
> @@ -1694,7 +1693,6 @@ static int ftdi_sio_port_probe(struct usb_serial_port 
> *port)
>   init_waitqueue_head(&priv->delta_msr_wait);
>  
>   priv->flags = ASYNC_LOW_LATENCY;
> - priv->dev_gone = false;
>  
>   if (quirk && quirk->port_probe)
>   quirk->port_probe(priv);
> @@ -1840,7 +1838,6 @@ static int ftdi_sio_port_remove(struct usb_serial_port 
> *port)
>  {
>   struct ftdi_private *priv = usb_get_serial_port_data(port);
>  
> - priv->dev_gone = true;
>   wake_up_interruptible_all(&priv->delta_msr_wait);
>  
>   remove_sysfs_attrs(port);
> @@ -2440,11 +2437,15 @@ static int ftdi_ioctl(struct tty_struct *tty,
>*/
>   case TIOCMIWAIT:
>   cprev = priv->icount;
> - while (!priv->dev_gone) {
> + for (;;) {
>   interruptible_sleep_on(&priv->delta_msr_wait);
>   /* see if a signal did it */
>   if (signal_pending(current))
>   return -ERESTARTSYS;
> +
> + if (port->serial->disconnected)
> + return -EIO;
> +
>   cnow = priv->icount;
>   if (((arg & TIOCM_RNG) && (cnow.rng != cprev.rng)) ||
>   ((arg & TIOCM_DSR) && (cnow.dsr != cprev.dsr)) ||
> @@ -2454,8 +2455,6 @@ static int ftdi_ioctl(struct tty_struct *tty,
>   }
>   cprev = cnow;
>   }
> - return -EIO;
> - break;
>   case TIOCSERGETLSR:
>   return get_lsr_info(port, (struct serial_struct __user *)arg);
>   break;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: misc: sisusbvga: Avoid NULL pointer dereference from sisusb

[Colin King]

From: Colin Ian King 

A failed kzalloc() is reported with a dev_err that dereferences the null
sisusb, this will cause a NULL pointer deference error.

Instead, pass dev->dev to the dev_err() rather than &sisusb->sisusb_dev->dev

Smatch analysis:

drivers/usb/misc/sisusbvga/sisusb.c:3087 sisusb_probe() error: potential null
  dereference 'sisusb'.  (kzalloc returns null)

Signed-off-by: Colin Ian King 
---
 drivers/usb/misc/sisusbvga/sisusb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/sisusbvga/sisusb.c 
b/drivers/usb/misc/sisusbvga/sisusb.c
index dd573ab..c21386e 100644
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -3084,7 +3084,7 @@ static int sisusb_probe(struct usb_interface *intf,
 
/* Allocate memory for our private */
if (!(sisusb = kzalloc(sizeof(*sisusb), GFP_KERNEL))) {
-   dev_err(&sisusb->sisusb_dev->dev, "Failed to allocate memory 
for private data\n");
+   dev_err(&dev->dev, "Failed to allocate memory for private 
data\n");
return -ENOMEM;
}
kref_init(&sisusb->kref);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Testing for hardware bug in EHCI controllers

[Sarah Sharp]

On Fri, Mar 15, 2013 at 11:08:12AM -0400, Alan Stern wrote:
> On Fri, 15 Mar 2013, Noone Nowhere wrote:
> 
> > Hello Alan again, we will clear things up. Sorry for the late reply,
> > dark forces delayed us.
> > 
> > 
> > > Intel probably doesn't care, because they don't make the affected
> > > chipsets any more.  I don't know what AMD is currently making.  Do you?
> > 
> > Yes we do. One of our ICH5 board uses ICH5 with SL7YC SL spec, meaning
> > it is an embedded chipset with extended availability so they must care
> > as it is paired with 865 and 875 series which are listed in
> > http://ark.intel.com/#DesktopProducts-DesktopChipsets and
> > http://ark.intel.com/products/27674/Intel-82801EB-IO-Controller for
> > ICH5. For AMD read below.
> 
> Sarah, do you know how I can report this to the right person at Intel?

I'll bubble up the results of this thread to our hardware team.  To the
original person who reported this (Noone?), can you privately send me
which company you work for?  Getting the name of an affected customer
will help expedite a fix for this.

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Alan Stern wrote:
> Roger just submitted my patch to split out ehci-omap.

Ok, if we can merge that for 3.9, the main issue will be resolved, because
an OMAP+Orion config is much more interesting in practice than adding
VT8500 to the mix.

An alternative for VT8500 would be to remove drivers/usb/host/ehci-vt8500.c
completely and use the generic ehci-platform.c bus glue with added DT
support, as the patch below that I just hacked up. Not sure if that
anyone would prefer that over the hot-fix for 3.9, but it's possibly
a better solution in the long run.

> What happened to Manjunath Goudar?  I haven't heard from him since his 
> first round of submissions a month ago.  Fixing them up shouldn't be 
> too much work.

He's still around and working on his patches for 3.10. I'm currently working
with him to resolve a few of the remaining problems in his series and he
will post the lot soon.

> As far as I can tell, your scheme should be okay for now.  It would be 
> good to hear from other people, though.
> 
> I'd guess that the only reason it wasn't done this way from the
> beginning is that nobody considered the possibility of building a
> multi-platform driver.

Right. It's been a long way until it became possible on ARM. The four
PowerPC bus glues have already been mutually exclusive like this all
the time.

Arnd


---
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index ca75063..2e4ddd4 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -18,11 +18,13 @@
  *
  * Licensed under the GNU/GPL. See COPYING for details.
  */
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,17 +43,21 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
int retval;
 
-   hcd->has_tt = pdata->has_tt;
-   ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug;
-   ehci->big_endian_desc = pdata->big_endian_desc;
-   ehci->big_endian_mmio = pdata->big_endian_mmio;
+   ehci->caps = hcd->regs;
+
+   if (pdata) {
+   hcd->has_tt = pdata->has_tt;
+   ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug;
+   ehci->big_endian_desc = pdata->big_endian_desc;
+   ehci->big_endian_mmio = pdata->big_endian_mmio;
+   ehci->caps += pdata->caps_offset;
+   }
 
-   ehci->caps = hcd->regs + pdata->caps_offset;
retval = ehci_setup(hcd);
if (retval)
return retval;
 
-   if (pdata->no_io_watchdog)
+   if (pdata && pdata->no_io_watchdog)
ehci->need_io_watchdog = 0;
return 0;
 }
@@ -70,11 +76,6 @@ static int ehci_platform_probe(struct platform_device *dev)
int irq;
int err = -ENOMEM;
 
-   if (!pdata) {
-   WARN_ON(1);
-   return -ENODEV;
-   }
-
if (usb_disabled())
return -ENODEV;
 
@@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device *dev)
return -ENXIO;
}
 
-   if (pdata->power_on) {
+   if (pdata && pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
return err;
}
 
+   if (!dev->dev.dma_mask) {
+   dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+   dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   }
+
hcd = usb_create_hcd(&ehci_platform_hc_driver, &dev->dev,
 dev_name(&dev->dev));
if (!hcd) {
@@ -121,7 +127,7 @@ static int ehci_platform_probe(struct platform_device *dev)
 err_put_hcd:
usb_put_hcd(hcd);
 err_power:
-   if (pdata->power_off)
+   if (pdata && pdata->power_off)
pdata->power_off(dev);
 
return err;
@@ -136,7 +142,7 @@ static int ehci_platform_remove(struct platform_device *dev)
usb_put_hcd(hcd);
platform_set_drvdata(dev, NULL);
 
-   if (pdata->power_off)
+   if (pdata && pdata->power_off)
pdata->power_off(dev);
 
return 0;
@@ -155,7 +161,7 @@ static int ehci_platform_suspend(struct device *dev)
 
ret = ehci_suspend(hcd, do_wakeup);
 
-   if (pdata->power_suspend)
+   if (pdata && pdata->power_suspend)
pdata->power_suspend(pdev);
 
return ret;
@@ -168,7 +174,7 @@ static int ehci_platform_resume(struct device *dev)
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
 
-   if (pdata->power_on) {
+   if (pdata && pdata->power_on) {
int err = pdata->power_on(pdev);
if (err < 0)
return err;
@@ -183,6 +189,12 @@ static int ehci_platform_resume(struct device *dev)
 #define ehci_platform_resume   NULL
 #endif /* CONFIG_PM */
 
+static const struct of_device_

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Alan Stern]

On Fri, 15 Mar 2013, Arnd Bergmann wrote:

> A number of ARM platforms were changed in linux-3.9 so they can be enabled
> at a single kernel configuration. Unfortunately, the necessary changes for
> the EHCI driver were not ready in time and the first attempt to split out
> the EHCI bus glues into separate modules had to get reverted before the
> merge window.
> 
> This means we are still stuck with a situation where enabling any
> combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
> platforms at the same time leaves us with an EHCI driver that does
> not work properly and spits out this build warning:
> 
> ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1257:0: note: this is the location of the previous definition
> ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1277:0: note: this is the location of the previous definition
> In file included from ehci-hcd.c:1256:0:
> ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used 
> [-Wunused-variable]
> In file included from ehci-hcd.c:1276:0:
> ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used 
> [-Wunused-variable]
> ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1257:0: note: this is the location of the previous definition
> ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
> ehci-hcd.c:1277:0: note: this is the location of the previous definition

Roger just submitted my patch to split out ehci-omap.

> This is the simplest patch I could come up with that will restore some
> sanity in multiplatform configuration and allow us to build an ARM
> allyesconfig kernel. Disallowing the broken configuration in Kconfig
> would actually end up in a larger patch and more regression potential
> than this one.
> 
> We had a similar situation in 3.8 with a conflict between Orion and MXC,
> and Alan Stern objected to the simple hack back then and instead provided
> a better full conversion of the MXC backend in patch dba63b2f7. A proper
> patch for OMAP was submitted in January but also did not make it into 3.9,
> see https://patchwork.kernel.org/patch/2055131.
> 
> I expect that for 3.10 we will be able to do this correctly and
> turn all ARM bus glues into separate modules, ripping out the
> code that this patch changes.

What happened to Manjunath Goudar?  I haven't heard from him since his 
first round of submissions a month ago.  Fixing them up shouldn't be 
too much work.

As far as I can tell, your scheme should be okay for now.  It would be 
good to hear from other people, though.

I'd guess that the only reason it wasn't done this way from the
beginning is that nobody considered the possibility of building a
multi-platform driver.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Greg KH wrote:

> > > > > I have the same problem on my Lenovo T500. I think the graphics card 
> > > > > is
> > > > > involved.
> > > > > 
> > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 
> > > > > 16:
> > > > > nobody cared" during boot, not when I boot with the ATI card.
> > > > 
> > > > Confirming this. After a lot of hassle, I have bisected this reliably to
> > > > 
> > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > > > Author: Daniel Vetter 
> > > > Date:   Sat Dec 1 13:53:45 2012 +0100
> > > > 
> > > > drm/i915: use the gmbus irq for waits
> > > > 
> > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out 
> > > > what's 
> > > > happening in parallel.
> > > 
> > > Wasn't this fixed by the merge from David
> > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
> > 
> > Why do you think it should, please?
> 
> The line:
>   - Fix PCH irq handling race which resulted in missed gmbus/dp
> aux irqs and subsequent fallout (Paulo)

Ah, that one. I believe that should be irrelevant for GM chipsets, as they 
don't have AUX line, right?

> > (I am seeing this with a2362d247 still).
> 
> Ok, I guess it isn't still fixed properly, just was guessing :)

Seems like this is a different issue.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/23] ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes

[Tony Lindgren]

Hi,

I think you can get rid of quite a bit more of the repeated data for
most boards, see below.

* Roger Quadros  [130315 08:21]:
> Add 2 platform devices for 'nop-usb-xceiv'. These will be used
> as PHYs for HS USB ports 1 and 2 so provide binding information
> for them.
> 
> Use usbhs_init_phys() to register the PHY's RESET regulators.
> 
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/mach-omap2/board-3430sdp.c |   47 ++
>  1 files changed, 41 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
> b/arch/arm/mach-omap2/board-3430sdp.c
> index ce812de..5584682 100644
> --- a/arch/arm/mach-omap2/board-3430sdp.c
> +++ b/arch/arm/mach-omap2/board-3430sdp.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -445,16 +446,37 @@ static void enable_board_wakeup_source(void)
>   OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
>  }
>  
> +/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
> +static struct platform_device hsusb1_phy_device = {
> + .name = "nop_usb_xceiv",
> + .id = 1,
> +};
> +
> +/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
> +static struct platform_device hsusb2_phy_device = {
> + .name = "nop_usb_xceiv",
> + .id = 2,
> +};

Please allocate these in the common ehci platform init code
so you don't have to repeat the same nop_usb_xceiv for each
board-*.c file. If you need to override these, then you can
pass something instead of NULL to the init function.

> +static struct usbhs_phy_data phy_data[] __initdata = {
> + {
> + .port = 1,
> + .reset_gpio = 57,
> + .vcc_gpio = -EINVAL,
> + .phy_id = "nop_usb_xceiv.1",
> + },
> + {
> + .port = 2,
> + .reset_gpio = 61,
> + .vcc_gpio = -EINVAL,
> + .phy_id = "nop_usb_xceiv.2",
> + },
> +};

This is OK as it's the board specific data needed. If it's the
same for many boards, then you might want to add some init function
for the default case.

> +static struct platform_device *sdp3430_devices[] __initdata = {
> + &hsusb1_phy_device,
> + &hsusb2_phy_device,
> +};

It then seems that this can be in the common ehci platform init
code for most cases.

>  static void __init omap_3430sdp_init(void)
>  {
>   int gpio_pendown;
> @@ -606,6 +633,14 @@ static void __init omap_3430sdp_init(void)
>   board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
>   sdp3430_display_init();
>   enable_board_wakeup_source();
> +
> + platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
> + /* PHY on HSUSB Port 1 i.e. index 0 */
> + usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
> + /* PHY on HSUSB Port 2 i.e. index 1 */
> + usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");

And this part too in most cases.

> + usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
>   usbhs_init(&usbhs_bdata);
>  }

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: musb: gadget: do *unmap_dma_buffer* only for valid DMA addr

[kishon]

On Friday 15 March 2013 08:09 PM, Felipe Balbi wrote:

From: Kishon Vijay Abraham I 

musb does not use DMA buffer for ep0 but it uses the same giveback
function *musb_g_giveback* for all endpoints (*musb_g_ep0_giveback* calls
*musb_g_giveback*). So for ep0 case request.dma will be '0'
and will result in kernel OOPS if tried to *unmap_dma_buffer* for requests in
ep0. Fixed it by doing *unmap_dma_buffer* only for valid DMA addr and
checking that musb_ep->dma is valid when unmapping.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Felipe Balbi 
---

Hi Kishon, this is how your patch looks like now,

do you think it's alright ? Since map_dma_buffer() checks
that musb_ep->dma is valid, I think we should do the same
thing when unmapping, what do you think ?

  drivers/usb/musb/musb_gadget.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index be18537..d9712bf 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -141,7 +141,7 @@ static inline void map_dma_buffer(struct musb_request 
*request,
  static inline void unmap_dma_buffer(struct musb_request *request,
struct musb *musb)
  {
-   if (!is_buffer_mapped(request))
+   if (!is_buffer_mapped(request) || !musb_ep->dma)
return;

if (request->request.dma == DMA_ADDR_INVALID) {
@@ -195,7 +195,10 @@ __acquires(ep->musb->lock)

ep->busy = 1;
spin_unlock(&musb->lock);
-   unmap_dma_buffer(req, musb);
+
+   if (!dma_mapping_error(request->dma))


this should have been *dma_mapping_error(&musb->g.dev, request->dma)* 
;-) But this doesn't work quite right. The dma_mapping_error considers 
only *DMA_ERROR_CODE* as error. Maybe we should have something like this


*if (!dma_mapping_error(&musb->g.dev, request->dma) && request->dma)*

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

On Friday 15 March 2013, Arnd Bergmann wrote:
> @@ -1409,10 +1409,20 @@ static int __init ehci_hcd_init(void)
> if (retval < 0)
> goto clean4;
>  #endif
> +
> +#ifdef OMAP_PLATFORM_DRIVER
> +   retval = platform_driver_register(&OMAP_PLATFORM_DRIVER);
> +   if (retval < 0)
> +   goto clean5;
> +#endif

There was a missing hunk for the ORION part like the one above since
I unfortunately had done this patch on the wrong base.  I will resubmit
a proper patch if we get an agreement on the approach taken.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] usb: Fix linker errors during build

[kishon]

On Friday 15 March 2013 07:55 PM, Felipe Balbi wrote:

On Fri, Mar 15, 2013 at 06:58:49PM +0530, Kishon Vijay Abraham I wrote:

commit 63378a (usb: phy: remove CONFIG_USB_OTG_UTILS) removed
CONFIG_USB_OTG_UTILS from Kconfig but failed to removed from Makefile.
Fixed it here.

Signed-off-by: Kishon Vijay Abraham I 


I can fold it in original commit since that's not in mainline yet,
thanks


Sure.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Greg KH]

On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Greg KH wrote:
> 
> > > > I have the same problem on my Lenovo T500. I think the graphics card is
> > > > involved.
> > > > 
> > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > > > nobody cared" during boot, not when I boot with the ATI card.
> > > 
> > > Confirming this. After a lot of hassle, I have bisected this reliably to
> > > 
> > >   commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > >   Author: Daniel Vetter 
> > >   Date:   Sat Dec 1 13:53:45 2012 +0100
> > > 
> > >   drm/i915: use the gmbus irq for waits
> > > 
> > > Adding Daniel, Imre and Daniel to CC while I will try to figure out 
> > > what's 
> > > happening in parallel.
> > 
> > Wasn't this fixed by the merge from David
> > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?
> 
> Why do you think it should, please?

The line:
- Fix PCH irq handling race which resulted in missed gmbus/dp
  aux irqs and subsequent fallout (Paulo)

> (I am seeing this with a2362d247 still).

Ok, I guess it isn't still fixed properly, just was guessing :)

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config

[Arnd Bergmann]

A number of ARM platforms were changed in linux-3.9 so they can be enabled
at a single kernel configuration. Unfortunately, the necessary changes for
the EHCI driver were not ready in time and the first attempt to split out
the EHCI bus glues into separate modules had to get reverted before the
merge window.

This means we are still stuck with a situation where enabling any
combination of more than one of the OMAP, MVEBU/Orion and VT8500/WM8x50
platforms at the same time leaves us with an EHCI driver that does
not work properly and spits out this build warning:

ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition
In file included from ehci-hcd.c:1256:0:
ehci-omap.c:311:31: warning: 'ehci_hcd_omap_driver' defined but not used 
[-Wunused-variable]
In file included from ehci-hcd.c:1276:0:
ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used 
[-Wunused-variable]
ehci-hcd.c:1277:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1257:0: note: this is the location of the previous definition
ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
ehci-hcd.c:1277:0: note: this is the location of the previous definition

This is the simplest patch I could come up with that will restore some
sanity in multiplatform configuration and allow us to build an ARM
allyesconfig kernel. Disallowing the broken configuration in Kconfig
would actually end up in a larger patch and more regression potential
than this one.

We had a similar situation in 3.8 with a conflict between Orion and MXC,
and Alan Stern objected to the simple hack back then and instead provided
a better full conversion of the MXC backend in patch dba63b2f7. A proper
patch for OMAP was submitted in January but also did not make it into 3.9,
see https://patchwork.kernel.org/patch/2055131.

I expect that for 3.10 we will be able to do this correctly and
turn all ARM bus glues into separate modules, ripping out the
code that this patch changes.

Signed-off-by: Arnd Bergmann 
Cc: Alan Stern 
Cc: Greg Kroah-Hartman 
Cc: Roger Quadros 
Cc: Andrew Lunn 
CC: Jason Cooper 
---
 drivers/usb/host/ehci-hcd.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index dd1d41d..c750d71 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1254,7 +1254,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_USB_EHCI_HCD_OMAP
 #include "ehci-omap.c"
-#definePLATFORM_DRIVER ehci_hcd_omap_driver
+#defineOMAP_PLATFORM_DRIVERehci_hcd_omap_driver
 #endif
 
 #ifdef CONFIG_PPC_PS3
@@ -1274,7 +1274,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_PLAT_ORION
 #include "ehci-orion.c"
-#definePLATFORM_DRIVER ehci_orion_driver
+#defineORION_PLATFORM_DRIVER   ehci_orion_driver
 #endif
 
 #ifdef CONFIG_USB_W90X900_EHCI
@@ -1409,10 +1409,20 @@ static int __init ehci_hcd_init(void)
if (retval < 0)
goto clean4;
 #endif
+
+#ifdef OMAP_PLATFORM_DRIVER
+   retval = platform_driver_register(&OMAP_PLATFORM_DRIVER);
+   if (retval < 0)
+   goto clean5;
+#endif
return retval;
 
+#ifdef OMAP_PLATFORM_DRIVER
+   /* platform_driver_unregister(&OMAP_PLATFORM_DRIVER); */
+clean5:
+#endif
 #ifdef XILINX_OF_PLATFORM_DRIVER
-   /* platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER); */
+   platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER);
 clean4:
 #endif
 #ifdef OF_PLATFORM_DRIVER
@@ -1423,6 +1433,10 @@ clean3:
ps3_ehci_driver_unregister(&PS3_SYSTEM_BUS_DRIVER);
 clean2:
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+   platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+clean1:
+#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
 clean0:
@@ -1439,12 +1453,18 @@ module_init(ehci_hcd_init);
 
 static void __exit ehci_hcd_cleanup(void)
 {
+#ifdef OMAP_PLATFORM_DRIVER
+   platform_driver_unregister(&OMAP_PLATFORM_DRIVER);
+#endif
 #ifdef XILINX_OF_PLATFORM_DRIVER
platform_driver_unregister(&XILINX_OF_PLATFORM_DRIVER);
 #endif
 #ifdef OF_PLATFORM_DRIVER
platform_driver_unregister(&OF_PLATFORM_DRIVER);
 #endif
+#ifdef ORION_PLATFORM_DRIVER
+   platform_driver_unregister(&ORION_PLATFORM_DRIVER);
+#endif
 #ifdef PLATFORM_DRIVER
platform_driver_unregister(&PLATFORM_DRIVER);
 #endif
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Greg KH wrote:

> > > I have the same problem on my Lenovo T500. I think the graphics card is
> > > involved.
> > > 
> > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > > nobody cared" during boot, not when I boot with the ATI card.
> > 
> > Confirming this. After a lot of hassle, I have bisected this reliably to
> > 
> > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
> > Author: Daniel Vetter 
> > Date:   Sat Dec 1 13:53:45 2012 +0100
> > 
> > drm/i915: use the gmbus irq for waits
> > 
> > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
> > happening in parallel.
> 
> Wasn't this fixed by the merge from David
> (2cc79544bd0aabb4b3cf467ead5df526d9134c64)?

Why do you think it should, please?

(I am seeing this with a2362d247 still).

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Testing for hardware bug in EHCI controllers

[Alan Stern]

On Fri, 15 Mar 2013, Noone Nowhere wrote:

> Hello ,here are the logs from the failing EHCI hosts(chipset-SL
> Spec/revision@mainboard-system):
> 
> 
> ICH4-SL66K@FIC VC37
> 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM
> (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) (prog-if 20
> [EHCI])
>   Subsystem: FIRST INTERNATIONAL Computer Inc Device [1509:9016]

> ICH5-SL7YC@ASRockP4i65G
> 00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER
> (ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02) (prog-if 20
> [EHCI])
>   Subsystem: ASRock Incorporation Device [1849:24d0]

> ICH5R-SL724@ASUS P4P800 SE
> 00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER
> (ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02) (prog-if 20
> [EHCI])
>   Subsystem: ASUSTeK Computer Inc. P4P800/P5P800 series motherboard 
> [1043:80a6]

> ICH7-SL8FX@ASRock P4i945GC
> 00:1d.7 USB Controller [0c03]: Intel Corporation N10/ICH 7 Family USB2
> EHCI Controller [8086:27cc] (rev 01) (prog-if 20 [EHCI])
>   Subsystem: ASRock Incorporation Device [1849:27cc]

> 8237S@ASRock P4VM900
> 00:10.4 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0
> [1106:3104] (rev 90) (prog-if 20 [EHCI])
>   Subsystem: ASRock Incorporation K7VT6 motherboard [1849:3104]

> A50M FCH-A13@COMPAQ CQ57
> This one has 2 EHCI controllers so we attach both(in fact it has 3 but
> 1 is disabled).
> 00:12.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI])
>   Subsystem: Hewlett-Packard Company Device [103c:3577]

> 00:16.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI
> SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] (prog-if 20 [EHCI])
>   Subsystem: Hewlett-Packard Company Device [103c:3577]

> This was the only host giving error message at the program:
> URB timed out; bug may be present
> Wrong URB completed

Evidently hardware from a large number of vendors is affected by this 
bug.  You have to wonder if they all got the intellectual property 
from a common source.

> We thought to use a NEC hub on our broken laptop in order to get the
> bug fixed by the hub but the results did not make us happy(stupid idea
> for stupid hardware). Additionally we have tested the program on two
> more different hubs. We haven't tested our 3.0 hub. Do you think there
> is any change to fall on a broken hub while running on a good host and
> make the error come to surface? Please mention if it has to be run on
> hubs. Here are the results:

Hubs will not make any difference.  There's no reason to use a hub.

> , hope you figure out what you need. You can now see the full picture,
> as said on the first message the subject must change because it is not
> intel specific. Intel though was consistent all their initial
> southbridges were broken while other vendors broke their good EHCI
> controller. Good luck with fixing, we can test any patch prior
> merging. Unfortunately one SiS 478 board died after POST and we
> couldn't test it so R.I.P until service!

Thank you very much for all the testing.  We may find that the
workaround isn't needed on certain chipsets, but we can't know which 
ones without testing them.

The workaround patch is here:

http://marc.info/?l=linux-usb&m=136215301302639&w=2

It will apply to a 3.8 kernel.  After applying that patch, you should
find that the EHCI bug doesn't show up.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Greg KH]

On Fri, Mar 15, 2013 at 02:33:13PM +0100, Jiri Kosina wrote:
> On Fri, 15 Mar 2013, Harald Arnesen wrote:
> 
> > I have the same problem on my Lenovo T500. I think the graphics card is
> > involved.
> > 
> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > nobody cared" during boot, not when I boot with the ATI card.
> 
> Confirming this. After a lot of hassle, I have bisected this reliably to
> 
>   commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
>   Author: Daniel Vetter 
>   Date:   Sat Dec 1 13:53:45 2012 +0100
> 
>   drm/i915: use the gmbus irq for waits
> 
> Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
> happening in parallel.

Wasn't this fixed by the merge from David
(2cc79544bd0aabb4b3cf467ead5df526d9134c64)?  I can't figure out the
exact commit that the merge message referred to though...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 01/23] usb: phy: nop: Add some parameters to platform data

[Roger Quadros]

Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.

Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.

Signed-off-by: Roger Quadros 
Acked-by: Felipe Balbi 
---
 include/linux/usb/nop-usb-xceiv.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/linux/usb/nop-usb-xceiv.h 
b/include/linux/usb/nop-usb-xceiv.h
index 28884c7..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -5,6 +5,11 @@
 
 struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
+   unsigned long clk_rate;
+
+   /* if set fails with -EPROBE_DEFER if can't get regulator */
+   unsigned int needs_vcc:1;
+   unsigned int needs_reset:1;
 };
 
 #if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE) && 
defined(MODULE))
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 03/23] ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data

[Roger Quadros]

Add platform device and data for 'nop-usb-xceiv'. This will be used
as PHY for HS USB port 1, so provide binding information for it.

Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name.

Signed-off-by: Roger Quadros 
Acked-by: Felipe Balbi 
---
 arch/arm/mach-omap2/board-omap4panda.c |   34 ++-
 1 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index b02c2f0..feffde6 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -132,12 +133,27 @@ static struct platform_device btwilink_device = {
.id = -1,
 };
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct nop_usb_xceiv_platform_data hsusb1_phy_data = {
+   /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+   .clk_rate = 1920,
+};
+
+static struct platform_device hsusb1_phy_device = {
+   .name   = "nop_usb_xceiv",
+   .id = 1,
+   .dev= {
+   .platform_data = &hsusb1_phy_data,
+   },
+};
+
 static struct platform_device *panda_devices[] __initdata = {
&leds_gpio,
&wl1271_device,
&panda_abe_audio,
&panda_hdmi_audio_codec,
&btwilink_device,
+   &hsusb1_phy_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
@@ -158,16 +174,6 @@ static struct gpio panda_ehci_gpios[] __initdata = {
 static void __init omap4_ehci_init(void)
 {
int ret;
-   struct clk *phy_ref_clk;
-
-   /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
-   phy_ref_clk = clk_get(NULL, "auxclk3_ck");
-   if (IS_ERR(phy_ref_clk)) {
-   pr_err("Cannot request auxclk3\n");
-   return;
-   }
-   clk_set_rate(phy_ref_clk, 1920);
-   clk_prepare_enable(phy_ref_clk);
 
/* disable the power to the usb hub prior to init and reset phy+hub */
ret = gpio_request_array(panda_ehci_gpios,
@@ -181,6 +187,14 @@ static void __init omap4_ehci_init(void)
gpio_export(GPIO_HUB_NRESET, 0);
gpio_set_value(GPIO_HUB_NRESET, 1);
 
+   /* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
+   ret = clk_add_alias("main_clk", "nop_usb_xceiv.1", "auxclk3_ck", NULL);
+   if (ret)
+   pr_err("Failed to add main_clk alias to auxclk3_ck\n");
+
+   /* PHY on HS USB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+
usbhs_init(&usbhs_bdata);
 
/* enable power to hub */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 04/23] ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes

[Roger Quadros]

Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.

The VCC and RESET will then be managed by the PHY driver.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-omap4panda.c |   37 +--
 1 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index feffde6..1c22880 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -147,6 +147,16 @@ static struct platform_device hsusb1_phy_device = {
},
 };
 
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = GPIO_HUB_NRESET,
+   .vcc_gpio = GPIO_HUB_POWER,
+   .vcc_polarity = 1,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+};
+
 static struct platform_device *panda_devices[] __initdata = {
&leds_gpio,
&wl1271_device,
@@ -158,35 +168,12 @@ static struct platform_device *panda_devices[] __initdata 
= {
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .phy_reset  = false,
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = -EINVAL,
-   .reset_gpio_port[2]  = -EINVAL
-};
-
-static struct gpio panda_ehci_gpios[] __initdata = {
-   { GPIO_HUB_POWER,   GPIOF_OUT_INIT_LOW,  "hub_power"  },
-   { GPIO_HUB_NRESET,  GPIOF_OUT_INIT_LOW,  "hub_nreset" },
 };
 
 static void __init omap4_ehci_init(void)
 {
int ret;
 
-   /* disable the power to the usb hub prior to init and reset phy+hub */
-   ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
-   if (ret) {
-   pr_err("Unable to initialize EHCI power/reset\n");
-   return;
-   }
-
-   gpio_export(GPIO_HUB_POWER, 0);
-   gpio_export(GPIO_HUB_NRESET, 0);
-   gpio_set_value(GPIO_HUB_NRESET, 1);
-
/* FREF_CLK3 provides the 19.2 MHz reference clock to the PHY */
ret = clk_add_alias("main_clk", "nop_usb_xceiv.1", "auxclk3_ck", NULL);
if (ret)
@@ -195,10 +182,8 @@ static void __init omap4_ehci_init(void)
/* PHY on HS USB Port 1 i.e. index 0 */
usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
 
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
-
-   /* enable power to hub */
-   gpio_set_value(GPIO_HUB_POWER, 1);
 }
 
 static struct omap_musb_board_data musb_board_data = {
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 02/23] ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()

[Roger Quadros]

This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled.

It also links the "vcc" and "reset" supplies to the
PHY's device ID that is supplied in the struct usbhs_phy_data
argument.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/usb-host.c |  138 +++-
 arch/arm/mach-omap2/usb.h  |9 +++
 2 files changed, 145 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 5706bdc..e788fe5 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -22,8 +22,11 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include "soc.h"
 #include "omap_device.h"
@@ -526,3 +529,134 @@ void __init usbhs_init(struct usbhs_omap_platform_data 
*pdata)
 }
 
 #endif
+
+static const char *reset_supply = "reset";
+static const char *vcc_supply = "vcc";
+
+/* Template for PHY regulators */
+static struct regulator_consumer_supply hsusb_reg_supplies[] = {
+   { /* .supply & .dev_name filled later */ },
+};
+
+static struct regulator_init_data hsusb_reg_data = {
+   .constraints = {
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+   .consumer_supplies  = hsusb_reg_supplies,
+   .num_consumer_supplies  = ARRAY_SIZE(hsusb_reg_supplies),
+};
+
+static struct fixed_voltage_config hsusb_reg_config = {
+   /* .supply_name filled later */
+   .microvolts = 330,
+   .gpio = -1, /* updated later */
+   .startup_delay = 7, /* 70msec */
+   .enable_high = 1,   /* updated later */
+   .enabled_at_boot = 0,   /* keep in RESET */
+   /* .init_data filled later */
+};
+
+static struct platform_device_info hsusb_reg_pdev_info = {
+   .name   = "reg-fixed-voltage",
+   .id = PLATFORM_DEVID_AUTO,
+};
+
+int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)
+{
+   struct regulator_consumer_supply *supplies;
+   struct regulator_init_data *reg_data;
+   struct fixed_voltage_config *config;
+   char *supply_name;
+   int i;
+
+   for (i = 0; i < num_phys; i++) {
+
+   if (!phy->phy_id || !phy->port) {
+   pr_info("%s: Invalid phy_id or port\n", __func__);
+   continue;
+   }
+
+   if (!gpio_is_valid(phy->reset_gpio))
+   goto check_vcc;
+
+   supplies = kmemdup(hsusb_reg_supplies,
+   ARRAY_SIZE(hsusb_reg_supplies) *
+   sizeof(struct regulator_consumer_supply),
+   GFP_KERNEL);
+   if (!supplies)
+   return -ENOMEM;
+
+   supplies->supply = reset_supply;
+   supplies->dev_name = phy->phy_id;
+
+   reg_data = kmemdup(&hsusb_reg_data, sizeof(hsusb_reg_data),
+   GFP_KERNEL);
+   if (!reg_data)
+   return -ENOMEM;
+
+   reg_data->consumer_supplies = supplies;
+
+   config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config),
+   GFP_KERNEL);
+   if (!config)
+   return -ENOMEM;
+
+   supply_name = kmalloc(14, GFP_KERNEL);
+   if (!supply_name)
+   return -ENOMEM;
+
+   scnprintf(supply_name, 13, "hsusb%d_reset", phy->port);
+   config->supply_name = supply_name;
+   config->gpio = phy->reset_gpio;
+   config->init_data = reg_data;
+
+   hsusb_reg_pdev_info.data = config;
+   hsusb_reg_pdev_info.size_data = sizeof(hsusb_reg_config);
+   platform_device_register_full(&hsusb_reg_pdev_info);
+
+check_vcc:
+   if (!gpio_is_valid(phy->vcc_gpio))
+   goto next;
+
+   supplies = kmemdup(hsusb_reg_supplies,
+   ARRAY_SIZE(hsusb_reg_supplies) *
+   sizeof(struct regulator_consumer_supply),
+   GFP_KERNEL);
+   if (!supplies)
+   return -ENOMEM;
+
+   supplies->supply = vcc_supply;
+   supplies->dev_name = phy->phy_id;
+
+   reg_data = kmemdup(&hsusb_reg_data, sizeof(hsusb_reg_data),
+   GFP_KERNEL);
+   if (!reg_data)
+   return -ENOMEM;
+
+   reg_data->consumer_supplies = supplies;
+
+   config = kmemdup(&hsusb_reg_config, sizeof(hsusb_reg_config),
+   GFP_KERNEL);
+   if (!config)
+   return -ENOMEM;
+
+   supply_name = kmalloc(14, GFP_KERNEL);
+   

[PATCH v2 00/23] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10

[Roger Quadros]

Hi Tony,

These patches provide the SoC side code required to support
the changes in the OMAP USB Host drivers done in [1], [2] & [3].

Device tree support is added for Beagleboard and Panda.

NOTE: The first patch needs to be shared between the
OMAP tree and Felipe's USB tree.

v2:
- Added helper function usbhs_init_phys() that can be used by board files
to simplify adding of PHY regulators for USB host ports.

[1] MFD side changes to omap-usb-host and omap-usb-tll
  https://lkml.org/lkml/2013/3/12/179
[2] USB EHCI side changes to ehci-omap 
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86265.html
[3] USB PHY driver changes
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg86293.html

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:
  git://github.com/rogerq/linux.git usbhost-arm-next

Roger Quadros (23):
  usb: phy: nop: Add some parameters to platform data
  ARM: OMAP2+: omap-usb-host: Add usbhs_init_phys()
  ARM: OMAP2+: omap4panda: Provide USB Host's PHY platform data
  ARM: OMAP2+: omap4panda: Adapt to ehci-omap changes
  ARM: OMAP3: Beagle: Adapt to ehci-omap changes
  ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes
  ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes
  ARM: OMAP: AM3517crane: Adapt to ehci-omap changes
  ARM: OMAP: AM3517evm: Adapt to ehci-omap changes
  ARM: OMAP3: cm-t35: Adapt to ehci-omap changes
  ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes
  ARM: OMAP: devkit8000: Adapt to ehci-omap changes
  ARM: OMAP3: igep0020: Adapt to ehci-omap changes
  ARM: OMAP3: omap3evm: Adapt to ehci-omap changes
  ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes
  ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes
  ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes
  ARM: OMAP3: overo: Adapt to ehci-omap changes
  ARM: OMAP: zoom: Adapt to ehci-omap changes
  ARM: dts: OMAP4: Add HS USB Host IP nodes
  ARM: dts: omap4-panda: Add USB Host support
  ARM: dts: OMAP3: Add HS USB Host IP nodes
  ARM: dts: omap3-beagle: Add USB Host support

 arch/arm/boot/dts/omap3-beagle.dts |   71 ++
 arch/arm/boot/dts/omap3.dtsi   |   31 ++
 arch/arm/boot/dts/omap4-panda.dts  |   56 +++
 arch/arm/boot/dts/omap4.dtsi   |   30 ++
 arch/arm/mach-omap2/board-3430sdp.c|   47 -
 arch/arm/mach-omap2/board-3630sdp.c|   48 +-
 arch/arm/mach-omap2/board-am3517crane.c|   38 +---
 arch/arm/mach-omap2/board-am3517evm.c  |   41 +++-
 arch/arm/mach-omap2/board-cm-t35.c |   45 -
 arch/arm/mach-omap2/board-cm-t3517.c   |   45 -
 arch/arm/mach-omap2/board-devkit8000.c |   20 +++--
 arch/arm/mach-omap2/board-igep0020.c   |   66 +++---
 arch/arm/mach-omap2/board-omap3beagle.c|   44 +++--
 arch/arm/mach-omap2/board-omap3evm.c   |   41 ++---
 arch/arm/mach-omap2/board-omap3pandora.c   |   31 +--
 arch/arm/mach-omap2/board-omap3stalker.c   |   29 +--
 arch/arm/mach-omap2/board-omap3touchbook.c |   38 ++--
 arch/arm/mach-omap2/board-omap4panda.c |   67 +++---
 arch/arm/mach-omap2/board-overo.c  |   32 +-
 arch/arm/mach-omap2/board-zoom.c   |   32 +-
 arch/arm/mach-omap2/usb-host.c |  138 +++-
 arch/arm/mach-omap2/usb.h  |9 ++
 include/linux/usb/nop-usb-xceiv.h  |5 +
 23 files changed, 849 insertions(+), 155 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 05/23] ARM: OMAP3: Beagle: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-omap3beagle.c |   44 ---
 1 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index c3558f9..566c434 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -277,6 +278,30 @@ static struct regulator_consumer_supply 
beagle_vsim_supply[] = {
 
 static struct gpio_led gpio_leds[];
 
+/* PHY's VCC regulator might be added later, so flag that we need it */
+static struct nop_usb_xceiv_platform_data hsusb2_phy_data = {
+   .needs_vcc = true,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+   .dev = {
+   .platform_data = &hsusb2_phy_data,
+   },
+};
+
+static struct usbhs_phy_data phy_data[] = {
+   {
+   .port = 2,
+   .reset_gpio = 147,
+   .vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
+   .vcc_polarity = 1,  /* updated in beagle_twl_gpio_setup */
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
 {
@@ -318,9 +343,11 @@ static int beagle_twl_gpio_setup(struct device *dev,
}
dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
 
-   gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
-   "nEN_USB_PWR");
+   /* TWL4030_GPIO_MAX i.e. LED_GPO controls HS USB Port 2 power */
+   phy_data[0].vcc_gpio = gpio + TWL4030_GPIO_MAX;
+   phy_data[0].vcc_polarity = beagle_config.usb_pwr_level;
 
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
return 0;
 }
 
@@ -450,18 +477,11 @@ static struct platform_device *omap3_beagle_devices[] 
__initdata = {
&keys_gpio,
&madc_hwmon,
&leds_pwm,
+   &hsusb2_phy_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
-   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = 147,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -543,7 +563,11 @@ static void __init omap3_beagle_init(void)
 
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
usbhs_init(&usbhs_bdata);
+
board_nand_init(omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions), NAND_CS,
NAND_BUSWIDTH_16, NULL);
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 07/23] ARM: OMAP3: 3630SDP: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.

Use usbhs_init_phys() to register the PHY's RESET regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-3630sdp.c |   48 ++
 1 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
b/arch/arm/mach-omap2/board-3630sdp.c
index 67447bd..4c205e3 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -53,16 +54,37 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
 }
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = 126,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+   {
+   .port = 2,
+   .reset_gpio = 61,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
 
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = 126,
-   .reset_gpio_port[1]  = 61,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -189,6 +211,11 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
 };
 
+static struct platform_device *sdp3630_devices[] __initdata = {
+   &hsusb1_phy_device,
+   &hsusb2_phy_device,
+};
+
 static void __init omap_sdp_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
@@ -199,6 +226,15 @@ static void __init omap_sdp_init(void)
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
enable_board_wakeup_source();
+
+   platform_add_devices(sdp3630_devices, ARRAY_SIZE(sdp3630_devices));
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
 }
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 09/23] ARM: OMAP: AM3517evm: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Port 1 and 2, so provide binding information for them.

Use usbhs_init_phys() to register the PHY's RESET regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-am3517evm.c |   41 -
 1 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 9fb8590..4e1283d 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -274,6 +275,27 @@ static __init void am3517_evm_mcbsp1_init(void)
omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
 }
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = 57,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
 #if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
@@ -282,12 +304,6 @@ static struct usbhs_omap_platform_data usbhs_bdata 
__initdata = {
 #else
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
 #endif
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = 57,
-   .reset_gpio_port[1]  = -EINVAL,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -349,6 +365,10 @@ static struct omap2_hsmmc_info mmc[] = {
{}  /* Terminator */
 };
 
+static struct platform_device *am3517evm_devices[] __initdata = {
+   &hsusb1_phy_device,
+   &hsusb2_phy_device,
+};
 
 static void __init am3517_evm_init(void)
 {
@@ -361,6 +381,15 @@ static void __init am3517_evm_init(void)
 
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
+
+   platform_add_devices(am3517evm_devices, ARRAY_SIZE(am3517evm_devices));
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
/* DSS */
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 11/23] ARM: OMAP3: cm-t3517: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.

Use usbhs_init_phys() to register the PHY's RESET regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-cm-t3517.c |   45 ++
 1 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index a66da80..5e64be1 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -188,15 +189,41 @@ static inline void cm_t3517_init_rtc(void) {}
 #define HSUSB2_RESET_GPIO  (147)
 #define USB_HUB_RESET_GPIO (152)
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = HSUSB1_RESET_GPIO,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+   {
+   .port = 2,
+   .reset_gpio = HSUSB2_RESET_GPIO,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct usbhs_omap_platform_data cm_t3517_ehci_pdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+};
 
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = HSUSB1_RESET_GPIO,
-   .reset_gpio_port[1]  = HSUSB2_RESET_GPIO,
-   .reset_gpio_port[2]  = -EINVAL,
+static struct platform_device *usbhs_devices[] = {
+   &hsusb1_phy_device,
+   &hsusb2_phy_device,
 };
 
 static int __init cm_t3517_init_usbh(void)
@@ -213,6 +240,14 @@ static int __init cm_t3517_init_usbh(void)
msleep(1);
}
 
+   platform_add_devices(usbhs_devices, ARRAY_SIZE(usbhs_devices));
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&cm_t3517_ehci_pdata);
 
return 0;
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Testing for hardware bug in EHCI controllers

[Alan Stern]

On Fri, 15 Mar 2013, Noone Nowhere wrote:

> USB stick on 12 different EHCI USB hosts. On VT8235M it took ages to
> go to 1000. A human readable timestamp could be used.

Evidently the VT8235M is very slow for some of the operations used by 
the test program.

> To sum up printing a start up message to leave it run up to 1000 is
> necessary

It is not necessary.  I mentioned this in the original email where the 
program was first distributed.

> as well as a warning to stop it using control+Z in avoid to
> avoid dmesg spamming.

Control-Z will not kill the program; the best way to stop it is to 
unplug the test device.  Doing this does not cause any dmesg spamming 
(unless you have CONFIG_USB_DEBUG enabled, in which case the extra 
messages are appropriate).

> Timestamps is another improvement

Why does anybody care about timestamps?

> and fixing the
> block count issue is the last one as on 2 controllers (moschip and
> SB850) the program exited immediately after initialization.

I can't fix the block count issue.  That's not a bug in the program; 
it's a bug somewhere else.

> First we
> must deal with those 2 controllers and check all hosts with the new
> version again. Since you prefer the logs with the current program, no
> problem. You will receive a message after this one with all the logs
> to keep you happy. Despite that, notice that when the program will be
> able to run on all hosts, we shall retest and resend the results. Are
> there any performance or reliability issues from this bug except the
> original DVB card detection problem? Will the workaround affect
> performance?

This EHCI bug is not related to DVB card detection.  I don't know what
original problem you're referring to.

A workaround for the bug has already been submitted to the various
stable kernel series.  The workaround may decrease performance slightly
for things like large data transfers to/from a mass-storage device.  I
haven't tried to measure the effect, and it will be different on
different platforms anyway.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 33/85] USB: serial: clean up usb-serial bus device removal

[Johan Hovold]

On Fri, Mar 15, 2013 at 08:02:45AM -0400, Peter Hurley wrote:
> On Thu, 2013-03-14 at 19:30 +0100, Johan Hovold wrote:
> > On Thu, Mar 14, 2013 at 01:39:39PM -0400, Peter Hurley wrote:
> > > On Thu, 2013-03-14 at 16:23 +0100, Johan Hovold wrote:
> > > > Make sure to unregister the tty-device before calling subdriver
> > > > port_remove.
> > > > 
> > > > This way remove will reverse probe, and specifically any port data
> > > > released in port_remove will be available throughout tty unregister.
> > > > 
> > > > Note that the order currently does not matter as the tty-layer can make
> > > > callbacks also after the device has been unregistered. This is
> > > > handled in usb-serial core using the disconnected flag, which is
> > > > already set when usb-serial bus device remove is called.
> > > > 
> > > > Cc: Peter Hurley 
> > > > Reported-by: Peter Hurley 
> > > > Signed-off-by: Johan Hovold 
> > > 
> > > Looks fine to me.
> > > 
> > > The thing I did notice is that the ftdi usb serial mini-driver has its
> > > own ioctl() handler for TIOCMIWAIT which can be holding the tty
> > > reference open after the unregister.
> > 
> > Yes, this is expected and perfectly fine. User-space may hold any
> > tty-ref indefinitely, but we must unregister the tty-device at
> > disconnect and then deal with it using the disconnected flag.
> > 
> > > Its port_remove() method, ftdi_sio_port_remove(), does the wake up to
> > > kick it off the loop.
> > 
> > Yes, all is good (except for another use-after free bug in that very
> > implementation that I fixed elsewhere). We hang up the port at
> > disconnect, unregister the device from the bus, which calls ftdi port
> > remove and wakes up any processes waiting on the delta_msr_wait queue,
> > which then return immediately based on the disconnected flag (this last
> > bit wasn't the case before the fix mentioned above but has nothing to
> > do with tty unregister).
> > 
> > > Now that the call order is reversed, that will need to be fixed.
> > 
> > No, the call order in usb-serial bus remove does not change anything
> > really. Any process doing TIOCMIWAIT will only be woken up slightly
> > later (and again there is nothing wrong in keeping a tty ref after tty
> > unregister).
> 
> I didn't mean it needed fixing because it would blow up; I just meant it
> needed fixing because it's not robust.
>
> Generally, if a tty driver needs to perform tty device-related cleanup,
> it should do so in the either the hangup() or close() call chain, not
> after it has knowingly unregistered the tty device.
> For the usb serial mini-drivers, this should be in their close()
> methods.

It's conceptually cleaner, yes. But as a tty-ref can be held indefinitely
(in particular, it can be held after having unregistered the device) and
the wake up is not synchronous, I don't see how not doing so would make
things any less robust, though.

> > > A quick review of the usage seems like the whole ioctl() should be
> > > torn out along with the private delta_msr_wait.
> > 
> > Most usb-serial TIOCIMWAIT-implementations, including the ftdi one, are
> > replaced by a generic implementation by this very series.
> 
> Ok. I have a look at those.

Either way, this series moves the wake-up from the individual driver's
port remove to usb-serial disconnect and before unregistering the device
from the bus.

However, looking at this again now, I realise that the wake up must be
done in hangup rather than disconnect (the common source for hangup in
usb-serial) in order to fully fix the problem with processes not being
woken up on hangup. (Perhaps, this is what you referred to with
"robust".)

I'll respin the series.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 12/23] ARM: OMAP: devkit8000: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.

Signed-off-by: Roger Quadros 
Acked-by: Felipe Balbi 
---
 arch/arm/mach-omap2/board-devkit8000.c |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..922ca91 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -33,6 +33,7 @@
 
 #include 
 #include 
+#include 
 #include "id.h"
 #include 
 #include 
@@ -430,22 +431,21 @@ static void __init omap_dm9000_init(void)
eth_addr[5] = (odi.id_0 & 0x00ff);
 }
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
 static struct platform_device *devkit8000_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
&omap_dm9000_dev,
+   &hsusb1_phy_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = -EINVAL,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -625,6 +625,10 @@ static void __init devkit8000_init(void)
 
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+
usbhs_init(&usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 14/23] ARM: OMAP3: omap3evm: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-omap3evm.c |   41 --
 1 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 48789e0..aaa01ae 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -496,7 +497,7 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata = 
{
 static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),/* OMAP ISP */
REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),/* OMAP ISP */
-   REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+   REGULATOR_SUPPLY("vcc", "nop_usb_xceiv.2"), /* hsusb port 2 */
REGULATOR_SUPPLY("vaux2", NULL),
 };
 
@@ -539,17 +540,27 @@ static int __init omap3_evm_i2c_init(void)
return 0;
 }
 
-static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
 
-   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = -1,   /* set at runtime */
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
 
-   .phy_reset  = true,
-   /* PHY reset GPIO will be runtime programmed based on EVM version */
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = -EINVAL,
-   .reset_gpio_port[2]  = -EINVAL
+static struct platform_device *omap3evm_devices[] __initdata = {
+   &hsusb2_phy_device,
+};
+
+static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
+   .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -725,7 +736,7 @@ static void __init omap3_evm_init(void)
 
/* setup EHCI phy reset config */
omap_mux_init_gpio(21, OMAP_PIN_INPUT_PULLUP);
-   usbhs_bdata.reset_gpio_port[1] = 21;
+   phy_data[0].reset_gpio = 21;
 
/* EVM REV >= E can supply 500mA with EXTVBUS programming */
musb_board_data.power = 500;
@@ -733,10 +744,16 @@ static void __init omap3_evm_init(void)
} else {
/* setup EHCI phy reset on MDC */
omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
-   usbhs_bdata.reset_gpio_port[1] = 135;
+   phy_data[0].reset_gpio = 135;
}
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(&musb_board_data);
+
+   platform_add_devices(omap3evm_devices, ARRAY_SIZE(omap3evm_devices));
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
board_nand_init(omap3evm_nand_partitions,
ARRAY_SIZE(omap3evm_nand_partitions), NAND_CS,
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 13/23] ARM: OMAP3: igep0020: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.

Use usbhs_init_phys() to register the PHY's RESET regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-igep0020.c |   66 ++---
 1 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index bf92678..8b0b2fb 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -527,26 +528,50 @@ static void __init igep_i2c_init(void)
omap3_pmic_init("twl4030", &igep_twldata);
 }
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data igep2_phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = IGEP2_GPIO_USBH_NRESET,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+};
+
+static struct usbhs_phy_data igep3_phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = IGEP3_GPIO_USBH_NRESET,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
+static struct platform_device *igep2_devices[] __initdata = {
+   &hsusb1_phy_device,
+};
+
+static struct platform_device *igep3_devices[] __initdata = {
+   &hsusb2_phy_device,
+};
+
 static struct usbhs_omap_platform_data igep2_usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset = true,
-   .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
-   .reset_gpio_port[1] = -EINVAL,
-   .reset_gpio_port[2] = -EINVAL,
 };
 
 static struct usbhs_omap_platform_data igep3_usbhs_bdata __initdata = {
-   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset = true,
-   .reset_gpio_port[0] = -EINVAL,
-   .reset_gpio_port[1] = IGEP3_GPIO_USBH_NRESET,
-   .reset_gpio_port[2] = -EINVAL,
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -642,8 +667,21 @@ static void __init igep_init(void)
if (machine_is_igep0020()) {
omap_display_init(&igep2_dss_data);
igep2_init_smsc911x();
+
+   platform_add_devices(igep2_devices, ARRAY_SIZE(igep2_devices));
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+
+   usbhs_init_phys(igep2_phy_data, ARRAY_SIZE(igep2_phy_data));
usbhs_init(&igep2_usbhs_bdata);
} else {
+   platform_add_devices(igep3_devices, ARRAY_SIZE(igep3_devices));
+
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(igep3_phy_data, ARRAY_SIZE(igep3_phy_data));
usbhs_init(&igep3_usbhs_bdata);
}
 }
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 10/23] ARM: OMAP3: cm-t35: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.

Use usbhs_init_phys() to register the PHY's RESET regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-cm-t35.c |   45 
 1 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index af2bb21..50a6517 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -419,15 +420,41 @@ static struct omap2_hsmmc_info mmc[] = {
{}  /* Terminator */
 };
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = OMAP_MAX_GPIO_LINES + 6,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+   {
+   .port = 2,
+   .reset_gpio = OMAP_MAX_GPIO_LINES + 7,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+};
 
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = OMAP_MAX_GPIO_LINES + 6,
-   .reset_gpio_port[1]  = OMAP_MAX_GPIO_LINES + 7,
-   .reset_gpio_port[2]  = -EINVAL
+static struct platform_device *usbhs_devices[] = {
+   &hsusb1_phy_device,
+   &hsusb2_phy_device,
 };
 
 static void  __init cm_t35_init_usbh(void)
@@ -444,6 +471,14 @@ static void  __init cm_t35_init_usbh(void)
msleep(1);
}
 
+   platform_add_devices(usbhs_devices, ARRAY_SIZE(usbhs_devices));
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
 }
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 08/23] ARM: OMAP: AM3517crane: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-am3517crane.c |   38 +-
 1 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517crane.c 
b/arch/arm/mach-omap2/board-am3517crane.c
index 7d3358b..f6ec36a 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -47,15 +48,28 @@ static struct omap_board_mux board_mux[] __initdata = {
 };
 #endif
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = GPIO_HUB_NRESET,
+   .vcc_gpio = GPIO_HUB_POWER,
+   .vcc_polarity = 1,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
+};
 
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = GPIO_USB_NRESET,
-   .reset_gpio_port[1]  = -EINVAL,
-   .reset_gpio_port[2]  = -EINVAL
+static struct platform_device *am3517_crane_devices[] __initdata = {
+   &hsusb1_phy_device,
 };
 
 static struct mtd_partition crane_nand_partitions[] = {
@@ -131,13 +145,13 @@ static void __init am3517_crane_init(void)
return;
}
 
-   ret = gpio_request_one(GPIO_USB_POWER, GPIOF_OUT_INIT_HIGH,
-  "usb_ehci_enable");
-   if (ret < 0) {
-   pr_err("Can not request GPIO %d\n", GPIO_USB_POWER);
-   return;
-   }
+   platform_add_devices(am3517_crane_devices,
+   ARRAY_SIZE(am3517_crane_devices));
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
 
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
 }
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 06/23] ARM: OMAP3: 3430SDP: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.

Use usbhs_init_phys() to register the PHY's RESET regulators.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-3430sdp.c |   47 ++
 1 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..5584682 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -445,16 +446,37 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
 }
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 1,
+   .reset_gpio = 57,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.1",
+   },
+   {
+   .port = 2,
+   .reset_gpio = 61,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
 
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = 57,
-   .reset_gpio_port[1]  = 61,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -585,6 +607,11 @@ static struct flash_partitions sdp_flash_partitions[] = {
},
 };
 
+static struct platform_device *sdp3430_devices[] __initdata = {
+   &hsusb1_phy_device,
+   &hsusb2_phy_device,
+};
+
 static void __init omap_3430sdp_init(void)
 {
int gpio_pendown;
@@ -606,6 +633,14 @@ static void __init omap_3430sdp_init(void)
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
enable_board_wakeup_source();
+
+   platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
 }
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 18/23] ARM: OMAP3: overo: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's RESET regulator.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-overo.c |   32 ++--
 1 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-overo.c 
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..024cc25 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -458,14 +459,27 @@ static int __init overo_spi_init(void)
return 0;
 }
 
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = OVERO_GPIO_USBH_NRESET,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
+static struct platform_device *overo_devices[] __initdata = {
+   &hsusb2_phy_device,
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = OVERO_GPIO_USBH_NRESET,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -502,6 +516,12 @@ static void __init overo_init(void)
ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+   platform_add_devices(overo_devices, ARRAY_SIZE(overo_devices));
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
overo_spi_init();
overo_init_smsc911x();
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 19/23] ARM: OMAP: zoom: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's RESET regulator.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-zoom.c |   32 ++--
 1 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom.c b/arch/arm/mach-omap2/board-zoom.c
index 5e4d4c9..220e07c 100644
--- a/arch/arm/mach-omap2/board-zoom.c
+++ b/arch/arm/mach-omap2/board-zoom.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -92,14 +93,27 @@ static struct mtd_partition zoom_nand_partitions[] = {
},
 };
 
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = ZOOM3_EHCI_RESET_GPIO,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
+static struct platform_device *zoom3_devices[] __initdata = {
+   &hsusb2_phy_device,
+};
+
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-   .port_mode[0]   = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1]   = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2]   = OMAP_USBHS_PORT_MODE_UNUSED,
-   .phy_reset  = true,
-   .reset_gpio_port[0] = -EINVAL,
-   .reset_gpio_port[1] = ZOOM3_EHCI_RESET_GPIO,
-   .reset_gpio_port[2] = -EINVAL,
 };
 
 static void __init omap_zoom_init(void)
@@ -109,6 +123,12 @@ static void __init omap_zoom_init(void)
} else if (machine_is_omap_zoom3()) {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
omap_mux_init_gpio(ZOOM3_EHCI_RESET_GPIO, OMAP_PIN_OUTPUT);
+
+   platform_add_devices(zoom3_devices, ARRAY_SIZE(zoom3_devices));
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
}
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 20/23] ARM: dts: OMAP4: Add HS USB Host IP nodes

[Roger Quadros]

Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.

CC: Benoît Cousson 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap4.dtsi |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..b7db1a2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = "timer11";
ti,timer-pwm;
};
+
+   usbhstll: usbhstll@4a062000 {
+   compatible = "ti,usbhs-tll";
+   reg = <0x4a062000 0x1000>;
+   interrupts = <0 78 0x4>;
+   ti,hwmods = "usb_tll_hs";
+   };
+
+   usbhshost: usbhshost@4a064000 {
+   compatible = "ti,usbhs-host";
+   reg = <0x4a064000 0x800>;
+   ti,hwmods = "usb_host_hs";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   usbhsohci: ohci@4a064800 {
+   compatible = "ti,ohci-omap3", "usb-ohci";
+   reg = <0x4a064800 0x400>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 76 0x4>;
+   };
+
+   usbhsehci: ehci@4a064c00 {
+   compatible = "ti,ehci-omap", "usb-ehci";
+   reg = <0x4a064c00 0x400>;
+   interrupt-parent = <&gic>;
+   interrupts = <0 77 0x4>;
+   };
+   };
};
 };
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 21/23] ARM: dts: omap4-panda: Add USB Host support

[Roger Quadros]

Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

Also provide pin multiplexer information for the USB host
pins.

CC: Benoît Cousson 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap4-panda.dts |   56 +
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..cfc7683 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,36 @@
"AFML", "Line In",
"AFMR", "Line In";
};
+
+   /* HS USB Port 1 RESET */
+   hsusb1_reset: hsusb1_reset_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb1_reset";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio2 30 0>;   /* gpio_62 */
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   /* HS USB Port 1 Power */
+   hsusb1_power: hsusb1_power_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb1_vbus";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio1 1 0>;/* gpio_1 */
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   /* HS USB Host PHY on PORT 1 */
+   hsusb1_phy: hsusb1_phy {
+   compatible = "usb-nop-xceiv";
+   reset-supply = <&hsusb1_reset>;
+   vcc-supply = <&hsusb1_power>;
+   clock-frequency = <1920>;
+   };
 };
 
 &omap4_pmx_core {
@@ -67,6 +97,7 @@
&mcbsp1_pins
&dss_hdmi_pins
&tpd12s015_pins
+   &hsusbb1_pins
>;
 
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +141,23 @@
0x58 0x10b  /* hdmi_hpd.gpio_63 INPUT PULLDOWN | 
MODE3 */
>;
};
+
+   hsusbb1_pins: pinmux_hsusbb1_pins {
+   pinctrl-single,pins = <
+   0x82 0x10C  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+   0x84 0x4/* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+   0x86 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+   0x88 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+   0x8a 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+   0x8c 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+   0x8e 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+   0x90 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+   0x92 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+   0x94 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+   0x96 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+   0x98 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+   >;
+   };
 };
 
 &i2c1 {
@@ -206,3 +254,11 @@
 &twl_usb_comparator {
usb-supply = <&vusb>;
 };
+
+&usbhshost {
+   port1-mode = "ehci-phy";
+};
+
+&usbhsehci {
+   phys = <&hsusb1_phy>;
+};
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 17/23] ARM: OMAP3: omap3touchbook: Adapt to ehci-omap changes

[Roger Quadros]

Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.

Use usbhs_init_phys() to register the PHY's RESET regulator.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-omap3touchbook.c |   38 ++-
 1 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c 
b/arch/arm/mach-omap2/board-omap3touchbook.c
index bcd44fb..e8fa884 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -36,6 +36,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include 
@@ -305,21 +306,37 @@ static struct omap_board_mux board_mux[] __initdata = {
 };
 #endif
 
+/* PHY device on HS USB Port 1 i.e. nop_usb_xceiv.1 */
+static struct platform_device hsusb1_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 1,
+};
+
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = 147,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct platform_device *omap3_touchbook_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
+   &hsusb1_phy_device,
+   &hsusb2_phy_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = 147,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 static void omap3_touchbook_poweroff(void)
@@ -368,6 +385,13 @@ static void __init omap3_touchbook_init(void)
omap_ads7846_init(4, OMAP3_TS_GPIO, 310, &ads7846_pdata);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+   /* PHY on HSUSB Port 1 i.e. index 0 */
+   usb_bind_phy("ehci-omap.0", 0, "nop_usb_xceiv.1");
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
board_nand_init(omap3touchbook_nand_partitions,
ARRAY_SIZE(omap3touchbook_nand_partitions), NAND_CS,
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 16/23] ARM: OMAP3: omap3stalker: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's RESET regulator.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-omap3stalker.c |   29 ++---
 1 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3stalker.c 
b/arch/arm/mach-omap2/board-omap3stalker.c
index 95c10b3..bf6a108 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -26,6 +26,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -358,19 +359,28 @@ static int __init omap3_stalker_i2c_init(void)
 
 #define OMAP3_STALKER_TS_GPIO  175
 
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = 21,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct platform_device *omap3_stalker_devices[] __initdata = {
&keys_gpio,
+   &hsusb2_phy_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset = true,
-   .reset_gpio_port[0] = -EINVAL,
-   .reset_gpio_port[1] = 21,
-   .reset_gpio_port[2] = -EINVAL,
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -407,6 +417,11 @@ static void __init omap3_stalker_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
+
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
omap_ads7846_init(1, OMAP3_STALKER_TS_GPIO, 310, NULL);
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 15/23] ARM: OMAP3: omap3pandora: Adapt to ehci-omap changes

[Roger Quadros]

Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.

Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.

Signed-off-by: Roger Quadros 
---
 arch/arm/mach-omap2/board-omap3pandora.c |   31 +
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index 2bba362..82a4fe3 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -346,7 +347,7 @@ static struct regulator_consumer_supply 
pandora_vcc_lcd_supply[] = {
 };
 
 static struct regulator_consumer_supply pandora_usb_phy_supply[] = {
-   REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+   REGULATOR_SUPPLY("vcc", "nop_usb_xceiv.2"), /* hsusb port 2 */
 };
 
 /* ads7846 on SPI and 2 nub controllers on I2C */
@@ -561,23 +562,31 @@ fail:
printk(KERN_ERR "wl1251 board initialisation failed\n");
 }
 
+/* PHY device on HS USB Port 2 i.e. nop_usb_xceiv.2 */
+static struct platform_device hsusb2_phy_device = {
+   .name = "nop_usb_xceiv",
+   .id = 2,
+};
+
+static struct usbhs_phy_data phy_data[] __initdata = {
+   {
+   .port = 2,
+   .reset_gpio = 16,
+   .vcc_gpio = -EINVAL,
+   .phy_id = "nop_usb_xceiv.2",
+   },
+};
+
 static struct platform_device *omap3pandora_devices[] __initdata = {
&pandora_leds_gpio,
&pandora_keys_gpio,
&pandora_vwlan_device,
&pandora_backlight,
+   &hsusb2_phy_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-
-   .port_mode[0] = OMAP_USBHS_PORT_MODE_UNUSED,
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-   .port_mode[2] = OMAP_USBHS_PORT_MODE_UNUSED,
-
-   .phy_reset  = true,
-   .reset_gpio_port[0]  = -EINVAL,
-   .reset_gpio_port[1]  = 16,
-   .reset_gpio_port[2]  = -EINVAL
 };
 
 #ifdef CONFIG_OMAP_MUX
@@ -601,7 +610,11 @@ static void __init omap3pandora_init(void)
spi_register_board_info(omap3pandora_spi_board_info,
ARRAY_SIZE(omap3pandora_spi_board_info));
omap_ads7846_init(1, OMAP3_PANDORA_TS_GPIO, 0, NULL);
+   /* PHY on HSUSB Port 2 i.e. index 1 */
+   usb_bind_phy("ehci-omap.0", 1, "nop_usb_xceiv.2");
+   usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
usbhs_init(&usbhs_bdata);
+
usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
gpmc_nand_init(&pandora_nand_data, NULL);
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 23/23] ARM: dts: omap3-beagle: Add USB Host support

[Roger Quadros]

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.

CC: Benoît Cousson 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap3-beagle.dts |   71 
 1 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..02d23f1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -38,6 +38,57 @@
};
};
 
+   /* HS USB Port 2 RESET */
+   hsusb2_reset: hsusb2_reset_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb2_reset";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio5 19 0>;   /* gpio_147 */
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
+   /* HS USB Port 2 Power */
+   hsusb2_power: hsusb2_power_reg {
+   compatible = "regulator-fixed";
+   regulator-name = "hsusb2_vbus";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&twl_gpio 18 0>;/* GPIO LEDA */
+   startup-delay-us = <7>;
+   };
+
+   /* HS USB Host PHY on PORT 2 */
+   hsusb2_phy: hsusb2_phy {
+   compatible = "usb-nop-xceiv";
+   reset-supply = <&hsusb2_reset>;
+   vcc-supply = <&hsusb2_power>;
+   };
+};
+
+&omap3_pmx_core {
+   pinctrl-names = "default";
+   pinctrl-0 = <
+   &hsusbb2_pins
+   >;
+
+   hsusbb2_pins: pinmux_hsusbb2_pins {
+   pinctrl-single,pins = <
+   0x5c0 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+   0x5c2 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+   0x5c4 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+   0x5c6 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+   0x5c8 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+   0x5cA 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+   0x1a4 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+   0x1a6 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+   0x1a8 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+   0x1aa 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+   0x1ac 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+   0x1ae 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+   >;
+   };
 };
 
 &i2c1 {
@@ -65,3 +116,23 @@
 &mmc3 {
status = "disabled";
 };
+
+&usbhshost {
+   port2-mode = "ehci-phy";
+};
+
+&usbhsehci {
+   phys = <0 &hsusb2_phy>;
+};
+
+&twl_gpio {
+   ti,use-leds;
+   /* pullups: BIT(1) */
+   ti,pullups = <0x02>;
+   /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+   ti,pulldowns = <0x03a1c4>;
+};
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 22/23] ARM: dts: OMAP3: Add HS USB Host IP nodes

[Roger Quadros]

Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.

CC: Benoît Cousson 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/omap3.dtsi |   31 +++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..a14f74b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,36 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   usbhstll: usbhstll@48062000 {
+   compatible = "ti,usbhs-tll";
+   reg = <0x48062000 0x1000>;
+   interrupts = <78>;
+   ti,hwmods = "usb_tll_hs";
+   };
+
+   usbhshost: usbhshost@48064000 {
+   compatible = "ti,usbhs-host";
+   reg = <0x48064000 0x400>;
+   ti,hwmods = "usb_host_hs";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   usbhsohci: ohci@48064400 {
+   compatible = "ti,ohci-omap3", "usb-ohci";
+   reg = <0x48064400 0x400>;
+   interrupt-parent = <&intc>;
+   interrupts = <76>;
+   };
+
+   usbhsehci: ehci@48064800 {
+   compatible = "ti,ehci-omap", "usb-ehci";
+   reg = <0x48064800 0x400>;
+   interrupt-parent = <&intc>;
+   interrupts = <77>;
+   };
+   };
+
};
 };
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Two remain problems at chipidea driver

[Alexander Shishkin]

Peter Chen  writes:

> On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote:
>> >> 
>> >> I'd say, in the core driver:
>> >>   1) get dr_mode from platform data
>> >>   2) only if that's DR_MODE_UNKNOWN (iirc), read DCCPARAMS, since it's
>> >>   not guaranteed to work across all chipideas;
>> >>   3) if dr_mode == OTG or dr_mode == UNKNOWN and DCCPARAMS has both DC
>> >>   and HC, set ci->otg, which determines if we can access otgsc
>> >>   4) if dr_mode == DUAL_ROLE, don't set ci->otg.
>> >> 
>> >> Do you see any problems with this?
>> >
>> > How to know vbus status if dr_mode == gadget, we need to indicate 
>> > connection
>> > and disconnection?
>> 
>> We don't. Do we need to indicate vbus session valid for gadget only
>> devices?
>
> Of course, eg,, how android phone know it connects to pc or not?

If nothing else, then at least it should be able to tell from the usb
phy. But I would be surprised if somebody uses a gadget-only usb
controller in a SoC that they use for an android phone or tablet. Most
probably it'll be dr_mode==USB_DR_MODE_OTG.

>> 
>> > if dr_mode == DUAL_ROLE, do we support ID switch? How can we know ID which
>> > ID pins connects to controller?
>> 
>> In this case we can support gpio-based or debugfs file-based role
>> switching.
>> 
>> > I think we need to split the relationship between dr_mode and OTG capable
>> > to cover this problem, eg, using another platform data to indicate if
>> > the controller supports OTG or not, since now we can't know if the 
>> > controller
>> > supports OTG or not from registers. And only OTG capable device can access
>> > OTGSC.
>> 
>> So that's what dr_mode already does in my suggestion above, isn't it?
>> dr_mode != OTG => no OTG; why do we need another platform field for?
>
> dr_mode stands for which controller operation mode currently 

What do you mean, "currently"? It *should* define what the controller is
capable of. Then, the current mode of operation can be either detected
from OTGSC or will simply default to HOST or PERIPHERAL, according to
dr_mode. IOW, dr_mode is a capability of the controller.

> otg_capable stands for whether the controller supports OTG operation

It is still redundant as

otg_capable = dr_mode == USB_DR_MODE_OTG

(same as ci->otg should be).

> Eg, for tablet or phone, the dr_mode may be "gadget", but the
> otg_capable = 1.

No, because dr_mode indicates controller's capability, and not the
"current" mode of operation. Why would anyone want to put *that* in a
DT?

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Jiri Kosina wrote:

> > I have the same problem on my Lenovo T500. I think the graphics card is
> > involved.
> > 
> > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> > nobody cared" during boot, not when I boot with the ATI card.
> 
> Confirming this. After a lot of hassle, I have bisected this reliably to
> 
>   commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
>   Author: Daniel Vetter 
>   Date:   Sat Dec 1 13:53:45 2012 +0100
> 
>   drm/i915: use the gmbus irq for waits
> 
> Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
> happening in parallel.
> 
> Attaching dmesg.txt from the machine with 28c70f162a as head, with 
> drm.debug=0xe.

Just a datapoint -- I have put a trivial debugging patch in place, and it 
reveals that "nobody cared" for irq 16 happens long after last

I915_WRITE(GMBUS4 + reg_offset, 0);

has been performed in gmbus_wait_hw_status(). On the other hand, if I 
comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), 
then it of course falls back to GPIO bit-banging, but the "nobody cared" 
for irq 16 is gone. 

So it seems like something gets severely confused by the I915_WRITE to 
GMBUS4 + reg_offset. So far this seems to have been reported solely on 
Lenovos as far as I can see (although a completely different types), so it 
might be some platform-specific quirk?

Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 
16 at all. 

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ccg USB gadget driver is now dead

[Greg KH]

On Fri, Mar 15, 2013 at 09:37:02AM +0200, Felipe Balbi wrote:
> On Thu, Mar 14, 2013 at 03:25:05PM -0700, Greg KH wrote:
> > FYI, I just applied this patch to my staging and USB trees, hopefully
> > this makes some people here happy.
> > 
> > 
> > 
> > From: Greg Kroah-Hartman 
> > Date: Thu, 14 Mar 2013 15:22:40 -0700
> > Subject: Staging: ccg: remove it from the build
> > 
> > This driver has been nothing but trouble, and no one shipping a new
> > Android device uses it, so let's just drop it, making the USB Gadget
> > driver authors lives a whole lot easier as they do their rework.
> > 
> > Cc: John Stultz 
> > Cc: Paul Bolle 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> thanks :-)
> 
> > ---
> >  drivers/staging/Kconfig  | 2 --
> >  drivers/staging/Makefile | 1 -
> >  2 files changed, 3 deletions(-)
> 
> But you forgot to actually delete the files, right ?

No, I did that in a separate patch in the staging-next tree.  I made
this a "simple" patch for the USB tree to take as well, so there
wouldn't be any "you deleted the same file in two different branches"
confusion.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Testing for hardware bug in EHCI controllers

[Alan Stern]

On Fri, 15 Mar 2013, Noone Nowhere wrote:

> Hello Alan again, we will clear things up. Sorry for the late reply,
> dark forces delayed us.
> 
> 
> > Intel probably doesn't care, because they don't make the affected
> > chipsets any more.  I don't know what AMD is currently making.  Do you?
> 
> Yes we do. One of our ICH5 board uses ICH5 with SL7YC SL spec, meaning
> it is an embedded chipset with extended availability so they must care
> as it is paired with 865 and 875 series which are listed in
> http://ark.intel.com/#DesktopProducts-DesktopChipsets and
> http://ark.intel.com/products/27674/Intel-82801EB-IO-Controller for
> ICH5. For AMD read below.

Sarah, do you know how I can report this to the right person at Intel?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] usb: fix PHY error handling

[Alan Stern]

On Fri, 15 Mar 2013, Felipe Balbi wrote:

> Hi Folks,
> 
> this patch set depends on [1] which makes PHY layer
> *always* return an error as suggested by Alan Stern.
> 
> I have compiled what I could, please go over the
> patches and give your Acked-by or NAK it if you think
> there's something wrong with any of the patches.
> 
> cheers
> 
> [1] http://marc.info/?l=linux-usb&m=136327710513124
> 
> Felipe Balbi (9):
>   usb: dwc3: fix PHY error handling
>   usb: gadget: mv_udc_core: fix PHY error handling
>   usb: gadget: s3c-hsotg: fix PHY error handling
>   usb: musb: omap2430: fix PHY error handling
>   usb: host: ehci-msm: fix PHY error handling
>   usb: host: ehci-mv: fix PHY error handling
>   usb: host: ehci-s5p: fix PHY error handling
>   usb: host: ehci-tegra: fix PHY error handling
>   usb: host: ohci-exynos: fix PHY error handling

Acked-by: Alan Stern 

for all the EHCI and OHCI changes.  But it would be good to have 
somebody test them.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux USB file storage gadget with new UDC

[Alan Stern]

On Fri, 15 Mar 2013, Felipe Balbi wrote:

> On Fri, Mar 15, 2013 at 04:26:10PM +0800, victor yeo wrote:
> > Hi,
> > 
> > > On Fri, Mar 15, 2013 at 01:59:30PM +0800, victor yeo wrote:
> > >> For bulk transfer, the new UDC driver has one problem. When SCSI
> > >> Inquiry command is received, the UDC driver interrupt routine will
> > >> receive it first. However, the queue function is not yet called, and
> > >> queue buffer is not yet added. Thus, interrupt routine is not able to
> > >> store the SCSI Inquiry command to the queue buffer.
> > >>
> > >> This is a serious problem, what is the way to synchronise UDC driver
> > >> and file storage gadget driver for SCSI command bulk transfer?
> > >
> > > don't process the interrupt until you receive a queue. Data will be
> > > pending in controller's FIFO until then.
> > >
> > 
> > change to do exactly that, bulk transfer interrupt come in, don't
> > process, then queue function is called to add  queue buffer. After
> > that, no more bulk transfer interrupt come in.
> 
> did you process the pending data from FIFO after queue was called ?

I'm not sure about the details of how the controller hardware works.  
But what should happen is this: When the controller receives the bulk 
packet containing the INQUIRY command, it should send back NAK until it 
has a buffer ready to store the packet.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/usb/gadget: beautify code, delete unused code

[Alan Stern]

On Fri, 15 Mar 2013, Felipe Balbi wrote:

> > Adding this back in revealed a bug in udc-core.  It is fixed as 
> > follows:
> > 
> > Index: usb-3.9/drivers/usb/gadget/udc-core.c
> > ===
> > --- usb-3.9.orig/drivers/usb/gadget/udc-core.c
> > +++ usb-3.9/drivers/usb/gadget/udc-core.c
> > @@ -216,7 +216,7 @@ static void usb_gadget_remove_driver(str
> > usb_gadget_disconnect(udc->gadget);
> > udc->driver->disconnect(udc->gadget);
> > udc->driver->unbind(udc->gadget);
> > -   usb_gadget_udc_stop(udc->gadget, udc->driver);
> > +   usb_gadget_udc_stop(udc->gadget, NULL);
> 
> BTW, this was only to maintain backwards compatibility during the
> conversion. I guess it's safe to remove the extra parameter. Very nice
> finding.

It wasn't exactly hard to spot.  When you get an oops, that's a pretty 
blatant indication that something's wrong.  :-)

> > udc->driver = NULL;
> > udc->dev.driver = NULL;
> > 
> > At the point where the UDC driver's stop routine is called, the gadget
> > no longer has a driver.  You might even want to move the line I changed 
> > down below the following two assignments, to make this more clear.
> > 
> > By the way, what happens if the UDC hardware doesn't support software 
> > control of the D+ pullup?  The usb_gadget_disconnect call above won't 
> > do anything, and that leaves open a window for a race.  The host might 
> > send a SETUP packet between the unbind and stop calls.  Should we 
> > insist that all UDC drivers do have a working ->pullup routine?
> 
> that would be one way. But, as you said, some controllers simply can't
> handle it.

Have those controllers been subject to this race all along?  If they 
have, I guess there's nothing we can do about it.  Otherwise we should 
try to fix it.

> > In addition, code-reading revealed a bug in an error pathway of
> > net2280.c:
> > 
> > Index: usb-3.9/drivers/usb/gadget/net2280.c
> > ===
> > --- usb-3.9.orig/drivers/usb/gadget/net2280.c
> > +++ usb-3.9/drivers/usb/gadget/net2280.c
> > @@ -1924,7 +1924,6 @@ static int net2280_start(struct usb_gadg
> >  err_func:
> > device_remove_file (&dev->pdev->dev, &dev_attr_function);
> >  err_unbind:
> > -   driver->unbind (&dev->gadget);
> > dev->gadget.dev.driver = NULL;
> > dev->driver = NULL;
> > return retval;
> > 
> > If the start method fails, udc_bind_to_driver() calls driver->unbind.  
> > The UDC driver doesn't need to do it.  I have not audited the other
> > gadget drivers for similar problems (i.e., unnecessary cleanup calls in
> > error pathways); it might be worth taking a quick look.  net2272 at
> > least probably has the same bug.
> > 
> > With these two fixes applied, everything seemed to work okay.  Should I
> > submit them officially?
> 
> please do. I guess we also want to Cc stable for v3.8 ;-)

Right.  Maybe even earlier; the udc-core bug has been present in one
form or another since 3.1.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: xhci: fix build warning

[Alan Stern]

On Fri, 15 Mar 2013, Peter Chen wrote:

> On Thu, Mar 14, 2013 at 10:59:45AM -0400, Alan Stern wrote:
> > On Thu, 14 Mar 2013, Peter Chen wrote:
> > 
> > > /home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: 
> > > In function ‘handle_port_status’:
> > > /home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580:
> > >  warning: ‘hcd’ may be used uninitialized in this function
> > > 
> > > Signed-off-by: Peter Chen 
> > > ---
> > >  drivers/usb/host/xhci-ring.c |4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > > index 8828754..17dace0 100644
> > > --- a/drivers/usb/host/xhci-ring.c
> > > +++ b/drivers/usb/host/xhci-ring.c
> > > @@ -1588,6 +1588,8 @@ static void handle_port_status(struct xhci_hcd 
> > > *xhci,
> > >   __le32 __iomem **port_array;
> > >   bool bogus_port_status = false;
> > >  
> > > + /* Find the right roothub. */
> > > + hcd = xhci_to_hcd(xhci);
> > >   /* Port status change events always have a successful completion code */
> > >   if (GET_COMP_CODE(le32_to_cpu(event->generic.field[2])) != 
> > > COMP_SUCCESS) {
> > >   xhci_warn(xhci, "WARN: xHC returned failed port status 
> > > event\n");
> > > @@ -1629,8 +1631,6 @@ static void handle_port_status(struct xhci_hcd 
> > > *xhci,
> > >* into the index into the ports on the correct split roothub, and the
> > >* correct bus_state structure.
> > >*/
> > > - /* Find the right roothub. */
> > > - hcd = xhci_to_hcd(xhci);
> > >   if ((major_revision == 0x03) != (hcd->speed == HCD_USB3))
> > >   hcd = xhci->shared_hcd;
> > 
> > You forgot to move these last two lines along with the first two.
> 
> No, major_revision is got above it.
> 
> In fact, the old logic is no problem due to flag bogus_port_status.

This doesn't matter.  Your change makes the code more fragile and
harder to understand, because in your version "hcd" is initialized in
two separate places.  The initialization should remain a single block
of code.

"Works okay" isn't good enough.  A lot of programmers seem to have
trouble absorbing this concept.  The code needs to be _clear_, because
it needs to continue to work correctly after other people make changes.  
If those other people can't understand it then they are likely to break
the code.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: musb: gadget: do *unmap_dma_buffer* only for valid DMA addr

[Felipe Balbi]

From: Kishon Vijay Abraham I 

musb does not use DMA buffer for ep0 but it uses the same giveback
function *musb_g_giveback* for all endpoints (*musb_g_ep0_giveback* calls
*musb_g_giveback*). So for ep0 case request.dma will be '0'
and will result in kernel OOPS if tried to *unmap_dma_buffer* for requests in
ep0. Fixed it by doing *unmap_dma_buffer* only for valid DMA addr and
checking that musb_ep->dma is valid when unmapping.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Felipe Balbi 
---

Hi Kishon, this is how your patch looks like now,

do you think it's alright ? Since map_dma_buffer() checks
that musb_ep->dma is valid, I think we should do the same
thing when unmapping, what do you think ?

 drivers/usb/musb/musb_gadget.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index be18537..d9712bf 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -141,7 +141,7 @@ static inline void map_dma_buffer(struct musb_request 
*request,
 static inline void unmap_dma_buffer(struct musb_request *request,
struct musb *musb)
 {
-   if (!is_buffer_mapped(request))
+   if (!is_buffer_mapped(request) || !musb_ep->dma)
return;
 
if (request->request.dma == DMA_ADDR_INVALID) {
@@ -195,7 +195,10 @@ __acquires(ep->musb->lock)
 
ep->busy = 1;
spin_unlock(&musb->lock);
-   unmap_dma_buffer(req, musb);
+
+   if (!dma_mapping_error(request->dma))
+   unmap_dma_buffer(req, musb);
+
if (request->status == 0)
dev_dbg(musb->controller, "%s done request %p,  %d/%d\n",
ep->end_point.name, request,
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: EHCI: fix for leaking isochronous data

[Alan Stern]

On Fri, 15 Mar 2013, Soeren Moch wrote:

> > The log shows a 1-1 match between allocations and deallocations, except
> > for three excess allocations about 45 lines before the end.  I have no
> > idea what's up with those.  They may be an artifact arising from where
> > you stopped copying the log data.
> >
> > There are as many as 400 iTDs being allocated before any are freed.
> > That seems like a lot.  Are they all for the same isochronous endpoint?
> > What's the endpoint's period?  How often are URBs submitted?
> 
> I use 2 dvb sticks, capturing digital TV. For each stick 5 URBs on a 
> single endpoint are used, I think. I'm not sure, which endpoint in which 
> alternateSetting is active. I attached the output of 'lsusb -v' for the 
> sticks.
> How can I track down the other information you need?

Use usbmon (see Documentation/usb/usbmon.txt).

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] usb: musb: gadget: do *unmap_dma_buffer* only for valid DMA addr

[Felipe Balbi]

On Fri, Mar 15, 2013 at 06:58:50PM +0530, Kishon Vijay Abraham I wrote:
> musb does not use DMA buffer for ep0 but it uses the same giveback
> function *musb_g_giveback* for all endpoints (*musb_g_ep0_giveback* calls
> *musb_g_giveback*). So for ep0 case request.dma will be '0'
> and will result in kernel OOPS if tried to *unmap_dma_buffer* for requests in
> ep0. Fixed it by doing *unmap_dma_buffer* only for valid DMA addr.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/musb/musb_gadget.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index c454375..ec3cf29 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -107,7 +107,10 @@ __acquires(ep->musb->lock)
>  
>   ep->busy = 1;
>   spin_unlock(&musb->lock);
> - unmap_dma_buffer(req, musb);
> +
> + if (request->dma)

I have changed to if (!dma_mapping_error(request->dma)), is it alright ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] usb: Fix linker errors during build

[Felipe Balbi]

On Fri, Mar 15, 2013 at 06:58:49PM +0530, Kishon Vijay Abraham I wrote:
> commit 63378a (usb: phy: remove CONFIG_USB_OTG_UTILS) removed
> CONFIG_USB_OTG_UTILS from Kconfig but failed to removed from Makefile.
> Fixed it here.
> 
> Signed-off-by: Kishon Vijay Abraham I 

I can fold it in original commit since that's not in mainline yet,
thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: gadget: f_mass_storage: add missing memory barrier for thread_wakeup_needed

[Michal Nazarewicz]

On Fri, Mar 15 2013, UCHINO Satoshi  wrote:
> Without this memory barrier, the file-storage thread may fail to
> escape from the following while loop, because it may observe new
> common->thread_wakeup_needed and old bh->state which are updated by
> the callback functions.
>
>   /* Wait for the CBW to arrive */
>   while (bh->state != BUF_STATE_FULL) {
>   rc = sleep_thread(common);
>   if (rc)
>   return rc;
>   }
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: UCHINO Satoshi 
> ---
>  drivers/usb/gadget/f_mass_storage.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/gadget/f_mass_storage.c 
> b/drivers/usb/gadget/f_mass_storage.c
> index fc5c16c..0b6d351 100644
> --- a/drivers/usb/gadget/f_mass_storage.c
> +++ b/drivers/usb/gadget/f_mass_storage.c
> @@ -414,6 +414,7 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct 
> usb_ep *ep)
>  static void wakeup_thread(struct fsg_common *common)
>  {
>   /* Tell the main thread that something has happened */
> + smp_wmb();
>   common->thread_wakeup_needed = 1;
>   if (common->thread_task)
>   wake_up_process(common->thread_task);
> @@ -632,6 +633,7 @@ static int sleep_thread(struct fsg_common *common)
>   }
>   __set_current_state(TASK_RUNNING);
>   common->thread_wakeup_needed = 0;
> + smp_rmb();
>   return rc;
>  }

In both places, add comment describing why the barrier is needed.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgp1Tcws3u8mW.pgp
Description: PGP signature

Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB

[kishon]

On Friday 15 March 2013 06:11 PM, Benoit Cousson wrote:

+ Jon

Hi Kishon,

On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote:

Hi Benoit,

Here are the dt data patches to get usb device functional in OMAP platforms.

All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt

Changes from v2:
* squashed the dt data for dwc3-omap with dwc3 core into a single patch.

Changes from v1:
Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with
names that has "_". It's replaced with a "-" here.

This patch is developed on Linux 3.9-rc1.


The patches looks really good. I've just had to rebase on top of my HEAD due to 
some conflict with GPMC patch already applied.

I cleaned as well some subject and changelog for consistency.


Ok. Thanks :-)

Regards
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Jiri Kosina]

On Fri, 15 Mar 2013, Harald Arnesen wrote:

> I have the same problem on my Lenovo T500. I think the graphics card is
> involved.
> 
> This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI
> Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16:
> nobody cared" during boot, not when I boot with the ATI card.

Confirming this. After a lot of hassle, I have bisected this reliably to

commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6
Author: Daniel Vetter 
Date:   Sat Dec 1 13:53:45 2012 +0100

drm/i915: use the gmbus irq for waits

Adding Daniel, Imre and Daniel to CC while I will try to figure out what's 
happening in parallel.

Attaching dmesg.txt from the machine with 28c70f162a as head, with 
drm.debug=0xe.

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] usb: Fix linker errors during build

[Kishon Vijay Abraham I]

commit 63378a (usb: phy: remove CONFIG_USB_OTG_UTILS) removed
CONFIG_USB_OTG_UTILS from Kconfig but failed to removed from Makefile.
Fixed it here.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/Makefile |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 860306b..c41feba 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -44,7 +44,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
 obj-$(CONFIG_USB_SERIAL)   += serial/
 
 obj-$(CONFIG_USB)  += misc/
-obj-$(CONFIG_USB_OTG_UTILS)+= phy/
+obj-$(CONFIG_USB_PHY)  += phy/
 obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/
 
 obj-$(CONFIG_USB_ATM)  += atm/
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] usb: musb: gadget: do *unmap_dma_buffer* only for valid DMA addr

[Kishon Vijay Abraham I]

musb does not use DMA buffer for ep0 but it uses the same giveback
function *musb_g_giveback* for all endpoints (*musb_g_ep0_giveback* calls
*musb_g_giveback*). So for ep0 case request.dma will be '0'
and will result in kernel OOPS if tried to *unmap_dma_buffer* for requests in
ep0. Fixed it by doing *unmap_dma_buffer* only for valid DMA addr.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/musb_gadget.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index c454375..ec3cf29 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -107,7 +107,10 @@ __acquires(ep->musb->lock)
 
ep->busy = 1;
spin_unlock(&musb->lock);
-   unmap_dma_buffer(req, musb);
+
+   if (request->dma)
+   unmap_dma_buffer(req, musb);
+
if (request->status == 0)
dev_dbg(musb->controller, "%s done request %p,  %d/%d\n",
ep->end_point.name, request,
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] usb: otg: twl4030: use devres API for regulator get and request irq

[Kishon Vijay Abraham I]

Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.

Signed-off-by: Kishon Vijay Abraham I 
Tested-by: Grazvydas Ignotas 
---
 drivers/usb/phy/phy-twl4030-usb.c |   28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index a994715..e14b03e 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -432,7 +432,7 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 3.1V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
 
-   twl->usb3v1 = regulator_get(twl->dev, "usb3v1");
+   twl->usb3v1 = devm_regulator_get(twl->dev, "usb3v1");
if (IS_ERR(twl->usb3v1))
return -ENODEV;
 
@@ -441,18 +441,18 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 1.5V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
 
-   twl->usb1v5 = regulator_get(twl->dev, "usb1v5");
+   twl->usb1v5 = devm_regulator_get(twl->dev, "usb1v5");
if (IS_ERR(twl->usb1v5))
-   goto fail1;
+   return -ENODEV;
 
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
 
/* Initialize 1.8V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
 
-   twl->usb1v8 = regulator_get(twl->dev, "usb1v8");
+   twl->usb1v8 = devm_regulator_get(twl->dev, "usb1v8");
if (IS_ERR(twl->usb1v8))
-   goto fail2;
+   return -ENODEV;
 
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
 
@@ -461,14 +461,6 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 TWL4030_PM_MASTER_PROTECT_KEY);
 
return 0;
-
-fail2:
-   regulator_put(twl->usb1v5);
-   twl->usb1v5 = NULL;
-fail1:
-   regulator_put(twl->usb3v1);
-   twl->usb3v1 = NULL;
-   return -ENODEV;
 }
 
 static ssize_t twl4030_usb_vbus_show(struct device *dev,
@@ -640,9 +632,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 * need both handles, otherwise just one suffices.
 */
twl->irq_enabled = true;
-   status = request_threaded_irq(twl->irq, NULL, twl4030_usb_irq,
-   IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
-   IRQF_ONESHOT, "twl4030_usb", twl);
+   status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
+   twl4030_usb_irq, IRQF_TRIGGER_FALLING |
+   IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
if (status < 0) {
dev_dbg(&pdev->dev, "can't get IRQ %d, err %d\n",
twl->irq, status);
@@ -663,7 +655,6 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
struct twl4030_usb *twl = platform_get_drvdata(pdev);
int val;
 
-   free_irq(twl->irq, twl);
device_remove_file(twl->dev, &dev_attr_vbus);
 
/* set transceiver mode to power on defaults */
@@ -685,9 +676,6 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
 
if (!twl->asleep)
twl4030_phy_power(twl, 0);
-   regulator_put(twl->usb1v5);
-   regulator_put(twl->usb1v8);
-   regulator_put(twl->usb3v1);
 
return 0;
 }
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] usb: otg: twl4030: fix cold plug on OMAP3

[Kishon Vijay Abraham I]

Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is ready.

Signed-off-by: Kishon Vijay Abraham I 
Tested-by: Grazvydas Ignotas 
---
 drivers/usb/phy/phy-twl4030-usb.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index e14b03e..1986c78 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -510,8 +510,9 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
return IRQ_HANDLED;
 }
 
-static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+static int twl4030_usb_phy_init(struct usb_phy *phy)
 {
+   struct twl4030_usb *twl = phy_to_twl(phy);
enum omap_musb_vbus_id_status status;
 
status = twl4030_usb_linkstat(twl);
@@ -528,6 +529,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
omap_musb_mailbox(twl->linkstat);
}
sysfs_notify(&twl->dev->kobj, NULL, "vbus");
+   return 0;
 }
 
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
@@ -604,6 +606,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->phy.otg= otg;
twl->phy.type   = USB_PHY_TYPE_USB2;
twl->phy.set_suspend= twl4030_set_suspend;
+   twl->phy.init   = twl4030_usb_phy_init;
 
otg->phy= &twl->phy;
otg->set_host   = twl4030_set_host;
@@ -641,11 +644,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
 
-   /* Power down phy or make it work according to
-* current link state.
-*/
-   twl4030_usb_phy_init(twl);
-
dev_info(&pdev->dev, "Initialized TWL4030 USB module\n");
return 0;
 }
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Two remain problems at chipidea driver

[Matthieu CASTET]

Peter Chen a écrit :
> On Fri, Mar 15, 2013 at 12:38:07PM +0200, Alexander Shishkin wrote:
 Do you see any problems with this?
>>> How to know vbus status if dr_mode == gadget, we need to indicate connection
>>> and disconnection?
>> We don't. Do we need to indicate vbus session valid for gadget only
>> devices?
> 
> Of course, eg,, how android phone know it connects to pc or not?

I don't know if there is a way to make vbus probing overidable :

- otg register
- use raw ulpi command to ask the phy
- use a gpio (if no upli phy or viewport) (for example otg/gpio_vbus.c) ?

Matthieu
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB

[Benoit Cousson]

+ Jon

Hi Kishon,

On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote:
> Hi Benoit,
> 
> Here are the dt data patches to get usb device functional in OMAP platforms.
> 
> All the patches deal with modifying arch/arm/boot except one which modifies
> Documentation/../usb/omap-usb.txt
> 
> Changes from v2:
> * squashed the dt data for dwc3-omap with dwc3 core into a single patch.
> 
> Changes from v1:
> Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with
> names that has "_". It's replaced with a "-" here.
> 
> This patch is developed on Linux 3.9-rc1.

The patches looks really good. I've just had to rebase on top of my HEAD due to 
some conflict with GPMC patch already applied.

I cleaned as well some subject and changelog for consistency.

The patches are available here:

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts


Jon,

You might have to rebase your series on top of the new HEAD before reposting.

Thanks,
Benoit


> Kishon Vijay Abraham I (7):
>   ARM: dts: omap: Add omap control usb data
>   ARM: dts: omap: Add omap-usb2 dt data
>   ARM: dts: omap: Add usb_otg and glue data
>   ARM: dts: omap5: Add omap control usb data
>   ARM: dts: omap5: Add ocp2scp data
>   ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data
>   ARM: dts: omap5: add dwc3 omap and dwc3 core dt data
> 
>  Documentation/devicetree/bindings/usb/omap-usb.txt |1 +
>  arch/arm/boot/dts/omap3-beagle-xm.dts  |6 +++
>  arch/arm/boot/dts/omap3-evm.dts|6 +++
>  arch/arm/boot/dts/omap3-overo.dtsi |6 +++
>  arch/arm/boot/dts/omap3.dtsi   |   12 +
>  arch/arm/boot/dts/omap4-panda.dts  |6 +++
>  arch/arm/boot/dts/omap4-sdp.dts|6 +++
>  arch/arm/boot/dts/omap4.dtsi   |   26 +++
>  arch/arm/boot/dts/omap5.dtsi   |   48 
> 
>  arch/arm/boot/dts/twl4030.dtsi |2 +-
>  10 files changed, 118 insertions(+), 1 deletion(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html