date:20130304

Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.

devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be removed from the failure code paths.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 drivers/usb/phy/samsung-usbphy.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 6ea5537..967101e 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -787,11 +787,9 @@ static int samsung_usbphy_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   phy_base = devm_request_and_ioremap(dev, phy_mem);
-   if (!phy_base) {
-   dev_err(dev, %s: register mapping failed\n, __func__);
-   return -ENXIO;
-   }
+   phy_base = devm_ioremap_resource(dev, phy_mem);
+   if (IS_ERR(phy_base))
+   return PTR_ERR(phy_base);
 
sphy = devm_kzalloc(dev, sizeof(*sphy), GFP_KERNEL);
if (!sphy)
-- 
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 2/3] usb: phy: omap-usb3: Convert to devm_ioremap_resource()

Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.

devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be removed from the failure code paths.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/phy/omap-usb3.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
index fadc0c2..a6e60b1 100644
--- a/drivers/usb/phy/omap-usb3.c
+++ b/drivers/usb/phy/omap-usb3.c
@@ -212,11 +212,9 @@ static int omap_usb3_probe(struct platform_device *pdev)
}
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, pll_ctrl);
-   phy-pll_ctrl_base = devm_request_and_ioremap(pdev-dev, res);
-   if (!phy-pll_ctrl_base) {
-   dev_err(pdev-dev, ioremap of pll_ctrl failed\n);
-   return -ENOMEM;
-   }
+   phy-pll_ctrl_base = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(phy-pll_ctrl_base))
+   return PTR_ERR(phy-pll_ctrl_base);
 
phy-dev= pdev-dev;
 
-- 
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 3/3] usb: phy: omap-control-usb: Convert to devm_ioremap_resource()

Use the newly introduced devm_ioremap_resource() instead of
devm_request_and_ioremap() which provides more consistent error handling.

devm_ioremap_resource() provides its own error messages; so all explicit
error messages can be removed from the failure code paths.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/phy/omap-control-usb.c |   24 +---
 1 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/phy/omap-control-usb.c 
b/drivers/usb/phy/omap-control-usb.c
index 5323b71..1419ced 100644
--- a/drivers/usb/phy/omap-control-usb.c
+++ b/drivers/usb/phy/omap-control-usb.c
@@ -219,32 +219,26 @@ static int omap_control_usb_probe(struct platform_device 
*pdev)
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
control_dev_conf);
-   control_usb-dev_conf = devm_request_and_ioremap(pdev-dev, res);
-   if (!control_usb-dev_conf) {
-   dev_err(pdev-dev, Failed to obtain io memory\n);
-   return -EADDRNOTAVAIL;
-   }
+   control_usb-dev_conf = devm_ioremap_resource(pdev-dev, res);
+   if (IS_ERR(control_usb-dev_conf))
+   return PTR_ERR(control_usb-dev_conf);
 
if (control_usb-type == OMAP_CTRL_DEV_TYPE1) {
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
otghs_control);
-   control_usb-otghs_control = devm_request_and_ioremap(
+   control_usb-otghs_control = devm_ioremap_resource(
pdev-dev, res);
-   if (!control_usb-otghs_control) {
-   dev_err(pdev-dev, Failed to obtain io memory\n);
-   return -EADDRNOTAVAIL;
-   }
+   if (IS_ERR(control_usb-otghs_control))
+   return PTR_ERR(control_usb-otghs_control);
}
 
if (control_usb-type == OMAP_CTRL_DEV_TYPE2) {
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
phy_power_usb);
-   control_usb-phy_power = devm_request_and_ioremap(
+   control_usb-phy_power = devm_ioremap_resource(
pdev-dev, res);
-   if (!control_usb-phy_power) {
-   dev_dbg(pdev-dev, Failed to obtain io memory\n);
-   return -EADDRNOTAVAIL;
-   }
+   if (IS_ERR(control_usb-phy_power))
+   return PTR_ERR(control_usb-phy_power);
 
control_usb-sys_clk = devm_clk_get(control_usb-dev,
sys_clkin);
-- 
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

2013-03-04 Thread Lan Tianyu

2013/2/26 Alan Stern st...@rowland.harvard.edu:
 Sarah (and anyone else who's interested):

 A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
 controllers.  You pointed out that these are rather old components, not
 being used in current systems, which is quite true.

 Now I have figured out a simple way for anyone to test for this bug in
 any EHCI controller, without the need for a g-zero gadget.  It's a
 two-part procedure:

 Apply the patch below (which is written for vanilla 3.8) and
 load the resulting driver.  The patch adds an explicit test
 to ehci-hcd for detecting the bug.

 Then plug in an ordinary USB flash drive and run the attached
 program (as root), giving it the device path for the flash
 drive as the single command-line argument.  For example:

 sudo ./ehci-test /dev/bus/usb/002/003

 The program won't do anything bad to the flash drive; it just reads the
 first 256 KB of data over and over again, now and then unlinking an URB
 to try and trigger the bug.  If the program works right, it will print
 out a loop counter every hundred iterations.  If it runs for 1000
 iterations with no error messages in the kernel log, you may consider
 that the controller has passed the test.  This should take under a
 minute, depending on the hardware speed.

 The program won't stop by itself unless something goes wrong.  You can
 kill it with ^C or more simply by unplugging the flash drive.  (If you
 want to be safe, make sure there are no mounted filesystems on the
 drive before running the test program.)

 If the hardware bug is detected, the kernel patch will print error
 messages to the system log.  For example, when I run the test on the
 Intel controller in this computer, I get:

 [  150.019441] usb-storage 3-8:1.0: disconnect by usbfs
 [  150.271190] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  150.591089] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  151.538560] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  151.857569] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  152.018886] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  152.179810] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  153.211804] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  153.374497] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  153.770443] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  154.247861] ehci-pci :00:1d.7: EHCI hardware bug detected: 82008d80 
 8d00
 [  154.566912] ehci-pci :00:1d.7: EHCI hardware bug detected: 82008d80 
 8d00
 [  155.359101] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  155.838132] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  156.791107] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  157.267620] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  159.252057] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  159.886048] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  160.206625] ehci-pci :00:1d.7: EHCI hardware bug detected: 02008d80 
 80008d00
 ...

 You get the idea.  The values in the two columns on the right are
 always supposed to be equal; when they aren't it indicates that the
 controller has done a DMA write at a time when ehci-hcd isn't expecting
 one to happen.

 I'd be interested to hear the results of testing on a variety of
 controllers.  (This computer also has an NEC EHCI controller, and that
 one does not have the bug.)  Do the EHCI controllers on current Intel
 chipsets pass the test?  What about other vendors?

 Thanks to all who try it out and report their results.
Test on the Sandybridge platform.
At the first time, I get following output. But after that, I was
hard to get any output. And test on the v3.8.

sudo ./ehci-test /dev/bus/usb/001/003
[  140.855342] usb-storage 1-1.2:1.0: disconnect by usbfs
Invalid URB stat[  140.863000] ehci-pci :00:1a.0: shutdown urb
88014545f300 ep1in-bulk
[  140.871303] ehci-pci :00:1a.0: shutdown urb 88014545f0c0 ep1in-bulk
[  140.878231] ehci-pci :00:1a.0: shutdown urb 88014545fcc0 ep1in-bulk
[  140.885158] ehci-pci :00:1a.0: shutdown urb 88014545fb40 ep1in-bulk
[  140.892088] ehci-pci :00:1a.0: shutdown urb 88014545f9c0 ep1in-bulk
[  140.899015] ehci-pci :00:1a.0: shutdown urb 88014545f780 ep1in-bulk
[  140.905941] ehci-pci :00:1a.0: shutdown urb 88014545f240 ep1in-bulk
[  140.912870] ehci-pci :00:1a.0: shutdown urb 88014545f900 ep1in-bulk
[  140.919799] ehci-pci :00:1a.0: shutdown urb 88014545fc00 ep1in-bulk
[  140.926725] ehci-pci :00:1a.0: shutdown urb

Re: [PATCH] fusb300_udc: modify stall clear and idma reset procedure

2013-03-04 Thread Yuan-Hsin Chen

Hi,

On Wed, Feb 27, 2013 at 1:59 AM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Fri, Feb 22, 2013 at 07:09:39AM +, Yuan-Hsin Chen wrote:
 From: Yuan-Hsin Chen yuan...@gmail.com

 Due to fusb300 controller modification, stall clear procedure should be
 modified consistantly. This patch also fixes software bugs: only
 enter IDMA_RESET when the condition matched and disable corresponding
 PRD interrupt in IDMA_RESET.


 Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com

 I have been trying to understand if this is a bug fix or if it can wait
 until v3.10.

There are a software bug fix and two corresponding fixes to hw register
 modification in the patch. Should it wait until v3.10?

 Also, according to your commit log, it seems like this patch is doing
 more than one thing, which is really frowned upon. Please split it up
 into separate logically self-contained changes. While doing that, make
 sure that your commit log explains the problem and the solution very
 well. Saying that because of a controller modification you need to
 change stall clear consistently isn't enough.

I will split it up and explain more clearly.
Thanks.

 Don't forget to mention how and with which platforms you tested.

 --
 balbi
--
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/3] usb: phy: samsung: Convert to devm_ioremap_resource()

2013-03-04 Thread Thierry Reding

On Mon, Mar 04, 2013 at 02:05:41PM +0530, Sachin Kamat wrote:
 Use the newly introduced devm_ioremap_resource() instead of
 devm_request_and_ioremap() which provides more consistent error handling.
 
 devm_ioremap_resource() provides its own error messages; so all explicit
 error messages can be removed from the failure code paths.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

Reviewed-by: Thierry Reding thierry.red...@avionic-design.de


pgpR2wexD4ouX.pgp
Description: PGP signature

Re: [PATCH 2/3] usb: phy: omap-usb3: Convert to devm_ioremap_resource()

2013-03-04 Thread Thierry Reding

On Mon, Mar 04, 2013 at 02:05:42PM +0530, Sachin Kamat wrote:
 Use the newly introduced devm_ioremap_resource() instead of
 devm_request_and_ioremap() which provides more consistent error handling.
 
 devm_ioremap_resource() provides its own error messages; so all explicit
 error messages can be removed from the failure code paths.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 Cc: Kishon Vijay Abraham I kis...@ti.com
 ---
  drivers/usb/phy/omap-usb3.c |8 +++-
  1 files changed, 3 insertions(+), 5 deletions(-)

Reviewed-by: Thierry Reding thierry.red...@avionic-design.de


pgpECQm4gcqfC.pgp
Description: PGP signature

Re: [PATCH 3/3] usb: phy: omap-control-usb: Convert to devm_ioremap_resource()

2013-03-04 Thread Thierry Reding

On Mon, Mar 04, 2013 at 02:05:43PM +0530, Sachin Kamat wrote:
 Use the newly introduced devm_ioremap_resource() instead of
 devm_request_and_ioremap() which provides more consistent error handling.
 
 devm_ioremap_resource() provides its own error messages; so all explicit
 error messages can be removed from the failure code paths.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 Cc: Kishon Vijay Abraham I kis...@ti.com
 ---
  drivers/usb/phy/omap-control-usb.c |   24 +---
  1 files changed, 9 insertions(+), 15 deletions(-)

Reviewed-by: Thierry Reding thierry.red...@avionic-design.de


pgpY3qVaPsu4D.pgp
Description: PGP signature

[PATCH 3.8-stable] usbnet: smsc95xx: fix suspend failure

The three below functions:

smsc95xx_enter_suspend0()
smsc95xx_enter_suspend1()
smsc95xx_enter_suspend2()

return  0 in case of success, so they will cause smsc95xx_suspend()
to return  0 and suspend failure.

This patch is backported from the upstream commit:

From 7643721471117d5f62ca36f328d3dc8d84af4402 Mon Sep 17 00:00:00 2001
Subject: [PATCH] usbnet: smsc95xx: fix suspend failure

Cc: sta...@vger.kernel.org
Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/net/usb/smsc95xx.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 9b73670..6214181 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1340,6 +1340,8 @@ static int smsc95xx_enter_suspend0(struct usbnet *dev)
ret = smsc95xx_read_reg_nopm(dev, PM_CTRL, val);
if (ret  0)
netdev_warn(dev-net, Error reading PM_CTRL\n);
+   else
+   ret = 0;
 
return ret;
 }
@@ -1392,6 +1394,8 @@ static int smsc95xx_enter_suspend1(struct usbnet *dev)
ret = smsc95xx_write_reg_nopm(dev, PM_CTRL, val);
if (ret  0)
netdev_warn(dev-net, Error writing PM_CTRL\n);
+   else
+   ret = 0;
 
return ret;
 }
@@ -1413,6 +1417,8 @@ static int smsc95xx_enter_suspend2(struct usbnet *dev)
ret = smsc95xx_write_reg_nopm(dev, PM_CTRL, val);
if (ret  0)
netdev_warn(dev-net, Error writing PM_CTRL\n);
+   else
+   ret = 0;
 
return ret;
 }
-- 
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: [PATCH v2 1/5] usb: chipidea: udc: move _ep_queue into an unlocked function

2013-03-04 Thread Michael Grzeschik

On Mon, Mar 04, 2013 at 10:44:25AM +0800, Peter Chen wrote:
 On Fri, Mar 01, 2013 at 03:42:23PM +0100, Michael Grzeschik wrote:
  There is no need to call ep_queue unlocked inside the own driver. We
  move its functionionality into an unlocked version.
  
  This patch removes potential unlocked timeslots inside
  isr_setup_status_phase and isr_get_status_response, in which the lock
  got released just before acquired again inside usb_ep_queue.
 
 You mean before or after?

I meant what i wrote.

The current lock juggling is as follows:

isr_setup_status_phase
..
unlock
lock   /* acquired inside usb_ep_queue */
..
unlock /* released inside usb_ep_queue */
lock
...

Instead of this, we can stay locked along the whole codepath.

 For other parts, it is ok, you can add:
 Reviewed-by: Peter Chen peter.c...@freescale.com

Thanks,
Michael
--
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 v10 6/8] usb: chipidea: imx: add internal vbus regulator control

Hi Greg,

On Wed, Feb 27, 2013 at 04:43:22PM +0200, Darius Augulis wrote:
 Hi balbi,
 
 actually no. I don't work with this hardware any more and don't have
 free time to support it.
 Please feel free to remove it if it breaks other things.

since nobody seems to care about imx_udc and it's currently even
including unexistent headers, I'll schedule it for removal on v3.11
(skipping v3.10 to give time for people to complain). Is that alright
with you ?

-- 
balbi


signature.asc
Description: Digital signature

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

2013-03-04 Thread David Härdeman

On Mon, Mar 04, 2013 at 09:22:04AM +0100, Hannes Reinecke wrote:
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.

Cc: Bjorn Helgaas bhelg...@google.com
Cc: Oliver Neukum oneu...@suse.de
Cc: Thomas Renninger tr...@suse.de
Cc: Yinghai Lu ying...@kernel.org
Cc: Frederik Himpe fhi...@vub.ac.be
Cc: David Haerdeman da...@hardeman.nu
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Hannes Reinecke h...@suse.de

No idea if it's the right solution but it works for me.

Tested-by: David Härdeman da...@hardeman.nu


diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 622b4a4..2647e75 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -173,6 +173,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
   struct hc_driver*driver;
   struct usb_hcd  *hcd;
   int retval;
+  int hcd_irq = 0;
 
   if (usb_disabled())
   return -ENODEV;
@@ -187,15 +188,21 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
   return -ENODEV;
   dev-current_state = PCI_D0;
 
-  /* The xHCI driver supports MSI and MSI-X,
-   * so don't fail if the BIOS doesn't provide a legacy IRQ.
+  /*
+   * The xHCI driver supports MSI and MSI-X,
+   * so don't fail if the BIOS doesn't provide a legacy IRQ
+   * and do not try to enable legacy IRQs.
*/
-  if (!dev-irq  (driver-flags  HCD_MASK) != HCD_USB3) {
-  dev_err(dev-dev,
-  Found HC with no IRQ.  Check BIOS/PCI %s setup!\n,
-  pci_name(dev));
-  retval = -ENODEV;
-  goto disable_pci;
+  if ((driver-flags  HCD_MASK) != HCD_USB3) {
+  if (!dev-irq) {
+  dev_err(dev-dev,
+  Found HC with no IRQ.  
+  Check BIOS/PCI %s setup!\n,
+  pci_name(dev));
+  retval = -ENODEV;
+  goto disable_pci;
+  }
+  hcd_irq = dev-irq;
   }
 
   hcd = usb_create_hcd(driver, dev-dev, pci_name(dev));
@@ -245,7 +252,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
 
   pci_set_master(dev);
 
-  retval = usb_add_hcd(hcd, dev-irq, IRQF_SHARED);
+  retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
   if (retval != 0)
   goto unmap_registers;
   set_hs_companion(dev, hcd);


-- 
David Härdeman
--
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

v3.8 regression: Huawei mode switching fails (was Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command)

Hello Franko,

This patch causes a number of regressions for both the Huawei devices I
have available for testing. One of them is completely unusable in v3.8
(unable to switch to modem mode) unless the usb-storage driver is
disabled.

I realize that some devices are historically handled by the usb-storage
driver, but userspace modeswitching is the rule for new devices AFAIK.
I see absolutely no valid argument for adding new devices.  And there is
absolutely no excuse for adding devices which have been handled by
userspace switching for years!  The patch does not just optimize
matching.  It adds a large number of devices which were previously
handled just fine by usb_modeswitch. This is guaranteed to confuse users
with existing configurations, and users looking up any of the existing
documentation pointing to usb_modeswitch.

There is no need to repeat the discussion of kernel vs userspace
switching.  I will only note that userspace switching:
 - has been selected as the rule for new devices,
 - allow the user to temporarily disable switching e.g. for mounting and
   inspecting the usb-storage exported data,
 - allow the user/system to apply device specific switching quirks


The v3.7-v3.8 regressions I observe are:

1) Temporarily disabling mode switching and mounting the CD image is now
  impossible. Mode switching can only be disabled by blacklisting
  usb-storage, which of course prevents usb-storage from working

  Prior to v3.8, modeswitching could easily be disabled by userspace
  configuration. The change breaks existing configurations.

2) Switching to non-default modes is now impossible.  The E392
 (initially appearing as 12d1:1505) Windows drivers will use a different
 command than the one used by Linux, causing the device to select a
 different configuration in Linux and Windows. This forces Linux and
 Windows to see the device differently.

 Prior to v3.8, different modeswitching commands could be configured 
 per device. The change breaks existing configurations.

3) Switching fails for some devices. The E367 (initially appearing as
 12d1:1446) does not switch when it receives the command sent by
 usb-storage.  But the command disable further switching, preventing
 userspace switching from working as well.

 Prior to v3.8, the device would switch fine using a default
 usb_modeswitch configuration. The change breaks existing
 configurations.

 I do note that there is a slight difference between the known working
 usb_modeswitch command:

   55534243123456780011062001

 and the command sent by usb-storage:

char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

 I assume the cause of the failure is either this difference or some
 timing issue.

Anyway, I believe this patch must be reverted.  It disables currently
used, well documented, and extremely useful, userspace funtionaliy for
all devices implicitly added by the conversion from device matching to
vendor matching.



Bjørn
--
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

[GIT PULL] usb: fixes for v3.9-rc2

Hi Greg,

Here's my first set of fixes for the v3.9-rc cycle. Nothing scary, all fixes
have been pending for a while now. I ran a few randconfig cycles with my
own seed, all looks good.

Let me know if you want any changes.

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v3.9-rc2

for you to fetch changes up to 29240e2392786c39007df2f4162f3dc4680f3dec:

  usb: gadget: u_uac1: NULL dereference on error path (2013-03-04 13:16:45 
+0200)


usb: fixes for v3.9-rc2

A few drivers got their gadget-dev registration problems
exposed by the removal of -start()/-stop() functions from
udc-core.c. All of such instances are now fixed.

We're also fixing chipidea's mistake of registering private
debugging sysfs files under the gadget's device. This is
in preparation to complete removal of gadget-dev handling
from all UDC drivers which will happen for v3.10 merge window.

MUSB's Kconfig got a fix to avoid a non-buildable selection
of its Kconfig choices.

Some extra devm_ioremap_resource() are added here because they
missed the merge window.

Finally, we have a temporary fix linking function drivers
before gadget drivers so they work fine when they're statically
linked to the kernel. We've done it so since the real fix wouldn't
fit the -rc cycle.


Dan Carpenter (2):
  usb: gadget: f_uac1: silence an info leak warning
  usb: gadget: u_uac1: NULL dereference on error path

Felipe Balbi (10):
  usb: dwc3: core: don't forget to free coherent memory
  usb: dwc3: omap: fix a typo on of_device_id
  usb: dwc3: glue layers shouldn't know about the core IP
  usb: dwc3: gadget: remove unnecessary code
  usb: chipidea: register debugging sysfs on our device
  usb: gadget: pxa27x: fix gadget-dev registration
  usb: gadget: s3c2410: fix gadget-dev registration
  usb: gadget: pxa25x: fix gadget-dev registration
  usb: gadget: imx_udc: fix gadget-dev registration
  usb: gadget: s3c2410: fix build breakage

Kishon Vijay Abraham I (1):
  usb: gadget: make usb functions to load before gadget driver

Marc Kleine-Budde (1):
  usb: otg: use try_module_get in all usb_get_phy functions and add missing 
module_put

Peter Ujfalusi (1):
  usb: musb: correct Kconfig in order to avoid non compilable selection

Sachin Kamat (3):
  usb: phy: samsung: Convert to devm_ioremap_resource()
  usb: phy: omap-usb3: Convert to devm_ioremap_resource()
  usb: phy: omap-control-usb: Convert to devm_ioremap_resource()

 drivers/usb/chipidea/udc.c |  6 +++---
 drivers/usb/dwc3/core.c|  1 +
 drivers/usb/dwc3/dwc3-exynos.c |  2 --
 drivers/usb/dwc3/dwc3-omap.c   |  8 +++-
 drivers/usb/dwc3/dwc3-pci.c|  2 --
 drivers/usb/dwc3/gadget.c  |  3 ---
 drivers/usb/gadget/Makefile| 12 ++--
 drivers/usb/gadget/f_uac1.c|  1 +
 drivers/usb/gadget/imx_udc.c   | 20 
 drivers/usb/gadget/pxa25x_udc.c| 20 +++-
 drivers/usb/gadget/pxa27x_udc.c| 18 --
 drivers/usb/gadget/s3c2410_udc.c   | 28 
 drivers/usb/gadget/u_uac1.c|  3 +++
 drivers/usb/musb/Kconfig   |  4 ++--
 drivers/usb/otg/otg.c  | 10 +++---
 drivers/usb/phy/omap-control-usb.c | 24 +---
 drivers/usb/phy/omap-usb3.c|  8 +++-
 drivers/usb/phy/samsung-usbphy.c   |  8 +++-
 18 files changed, 84 insertions(+), 94 deletions(-)
--
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 -v3 13/23] uwb: rename random32() to prandom_u32()

2013-03-04 Thread Akinobu Mita

Use more preferable function name which implies using a pseudo-random
number generator.

Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: linux-usb@vger.kernel.org
---

No change from v2

 drivers/uwb/rsv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/uwb/rsv.c b/drivers/uwb/rsv.c
index 0b0d8bc..f4ae05f 100644
--- a/drivers/uwb/rsv.c
+++ b/drivers/uwb/rsv.c
@@ -231,7 +231,7 @@ void uwb_rsv_backoff_win_increment(struct uwb_rc *rc)
return;
 
bow-window = 1;
-   bow-n = random32()  (bow-window - 1);
+   bow-n = prandom_u32()  (bow-window - 1);
dev_dbg(dev, new_window=%d, n=%d\n: , bow-window, bow-n);
 
/* reset the timer associated variables */
@@ -557,7 +557,7 @@ int uwb_rsv_establish(struct uwb_rsv *rsv)
if (ret)
goto out;
 
-   rsv-tiebreaker = random32()  1;
+   rsv-tiebreaker = prandom_u32()  1;
/* get available mas bitmap */
uwb_drp_available(rc, available);
 
-- 
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: [PATCH][v2] xhci: correctly enable interrupts

2013-03-04 Thread Sergei Shtylyov


Hello.

On 04-03-2013 12:22, Hannes Reinecke wrote:


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.



Cc: Bjorn Helgaas bhelg...@google.com
Cc: Oliver Neukum oneu...@suse.de
Cc: Thomas Renninger tr...@suse.de
Cc: Yinghai Lu ying...@kernel.org
Cc: Frederik Himpe fhi...@vub.ac.be
Cc: David Haerdeman da...@hardeman.nu
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Hannes Reinecke h...@suse.de



diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 622b4a4..2647e75 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c

[...]

@@ -187,15 +188,21 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return -ENODEV;
dev-current_state = PCI_D0;

-   /* The xHCI driver supports MSI and MSI-X,
-* so don't fail if the BIOS doesn't provide a legacy IRQ.
+   /*
+* The xHCI driver supports MSI and MSI-X,
+* so don't fail if the BIOS doesn't provide a legacy IRQ
+* and do not try to enable legacy IRQs.
 */
-   if (!dev-irq  (driver-flags  HCD_MASK) != HCD_USB3) {
-   dev_err(dev-dev,
-   Found HC with no IRQ.  Check BIOS/PCI %s setup!\n,
-   pci_name(dev));
-   retval = -ENODEV;
-   goto disable_pci;
+   if ((driver-flags  HCD_MASK) != HCD_USB3) {
+   if (!dev-irq) {
+   dev_err(dev-dev,
+   Found HC with no IRQ.  
+   Check BIOS/PCI %s setup!\n,


   The message strings are allowed to take more than 80 chars (to facilitate 
grepping for them), so no need to break this one; checkpatch.pl should not 
complain...



+   pci_name(dev));
+   retval = -ENODEV;
+   goto disable_pci;
+   }
+   hcd_irq = dev-irq;
}

hcd = usb_create_hcd(driver, dev-dev, pci_name(dev));


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: [V8 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

On Wed, Feb 20, 2013 at 11:07:11PM -0500, Chao Xie wrote:
 The PHY is seperated from usb controller.
 The usb controller used in marvell pxa168/pxa910/mmp2 are same,
 but PHY initialization may be different.
 the usb controller can support udc/otg/ehci, and for each of
 the mode, it need PHY to initialized before use the controller.
 Direclty writing the phy driver will make the usb controller
 driver to be simple and portable.
 The PHY driver will be used by marvell udc/otg/ehci.
 
 Signed-off-by: Chao Xie chao@marvell.com
 ---
  drivers/usb/phy/Kconfig  |7 +
  drivers/usb/phy/Makefile |1 +
  drivers/usb/phy/mv_usb2_phy.c|  402 
 ++
  include/linux/platform_data/mv_usb.h |9 +-
  include/linux/usb/mv_usb2.h  |   32 +++
  5 files changed, 448 insertions(+), 3 deletions(-)
  create mode 100644 drivers/usb/phy/mv_usb2_phy.c
  create mode 100644 include/linux/usb/mv_usb2.h
 
 diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
 index 65217a5..5479760 100644
 --- a/drivers/usb/phy/Kconfig
 +++ b/drivers/usb/phy/Kconfig
 @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY
   help
 Enable this to support Samsung USB phy controller for samsung
 SoCs.
 +
 +config MV_USB2_PHY
 + tristate Marvell USB 2.0 PHY Driver
 + depends on USB || USB_GADGET

NAK, PHYs don't depend on the gadget framework.

 + help
 +   Enable this to support Marvell USB 2.0 phy driver for Marvell
 +   SoC.
 diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
 index b13faa1..3835316 100644
 --- a/drivers/usb/phy/Makefile
 +++ b/drivers/usb/phy/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY)+= mv_u3d_phy.o
  obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
  obj-$(CONFIG_USB_RCAR_PHY)   += rcar-phy.o
  obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
 +obj-$(CONFIG_MV_USB2_PHY)+= mv_usb2_phy.o
 diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c
 new file mode 100644
 index 000..a81e5e4
 --- /dev/null
 +++ b/drivers/usb/phy/mv_usb2_phy.c
 @@ -0,0 +1,402 @@
 +/*
 + * Copyright (C) 2013 Marvell Inc.
 + *
 + * Author:
 + *   Chao Xie xiechao.m...@gmail.com
 + *
 + * 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.
 + *
 + */
 +
 +#include linux/resource.h
 +#include linux/delay.h
 +#include linux/slab.h
 +#include linux/of.h
 +#include linux/of_device.h
 +#include linux/io.h
 +#include linux/err.h
 +#include linux/clk.h
 +#include linux/export.h
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/platform_data/mv_usb.h
 +#include linux/usb/phy.h
 +#include linux/usb/mv_usb2.h
 +
 +/* phy regs */
 +#define UTMI_REVISION0x0
 +#define UTMI_CTRL0x4
 +#define UTMI_PLL 0x8
 +#define UTMI_TX  0xc
 +#define UTMI_RX  0x10
 +#define UTMI_IVREF   0x14
 +#define UTMI_T0  0x18
 +#define UTMI_T1  0x1c
 +#define UTMI_T2  0x20
 +#define UTMI_T3  0x24
 +#define UTMI_T4  0x28
 +#define UTMI_T5  0x2c
 +#define UTMI_RESERVE 0x30
 +#define UTMI_USB_INT 0x34
 +#define UTMI_DBG_CTL 0x38
 +#define UTMI_OTG_ADDON   0x3c

prepend these with MV_USB_

 +enum mv_usb2_phy_type {
 + PXA168_USB,
 + PXA910_USB,
 + MMP2_USB,
 +};
 +
 +static unsigned int u2o_get(void __iomem *base, unsigned int offset)
 +{
 + return readl(base + offset);
 +}
 +
 +static void u2o_set(void __iomem *base, unsigned int offset,
 + unsigned int value)
 +{
 + u32 reg;
 +
 + reg = readl(base + offset);
 + reg |= value;
 + writel(reg, base + offset);
 + /*
 +  * read after write. It will make sure writing takes effect.
 +  * It is suggested by PHY design engineer.
 +  */
 + readl(base + offset);

ewww... you really don't need (and *shouldn't* use) u2o_set() or
u2o_clear(). They clearly prevent compiler from optimizing variable
usage and could cause pressure on your interconnect. By writing and
reading multiple times for no reason.

 +static int _mv_usb2_phy_init(struct mv_usb2_phy *mv_phy)
 +{
 + struct platform_device *pdev = mv_phy-pdev;
 + unsigned int loops = 0;
 + void __iomem *base = mv_phy-base;
 +
 + dev_dbg(pdev-dev, phy init\n);

remove this debugging message.

 + /* Initialize the USB PHY power */
 + if (mv_phy-type ==

Re: [V8 PATCH 02/16] usb: gadget: mv_udc: use PHY driver for udc

On Wed, Feb 20, 2013 at 11:07:12PM -0500, Chao Xie wrote:
 Originaly, udc driver will call the callbacks in platform data
 for PHY initialization and shut down.
 With PHY driver, it will call the APIs provided by PHY driver
 for PHY initialization and shut down. It removes the callbacks
 in platform data, and at same time it removes one block in the
 way of enabling device tree for udc driver.
 
 Signed-off-by: Chao Xie chao@marvell.com
 ---
  drivers/usb/gadget/mv_udc.h  |2 +-
  drivers/usb/gadget/mv_udc_core.c |   45 ++---
  2 files changed, 18 insertions(+), 29 deletions(-)
 
 diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
 index 9073436..f339df4 100644
 --- a/drivers/usb/gadget/mv_udc.h
 +++ b/drivers/usb/gadget/mv_udc.h
 @@ -180,7 +180,6 @@ struct mv_udc {
  
   struct mv_cap_regs __iomem  *cap_regs;
   struct mv_op_regs __iomem   *op_regs;
 - void __iomem*phy_regs;
   unsigned intmax_eps;
   struct mv_dqh   *ep_dqh;
   size_t  ep_dqh_size;
 @@ -217,6 +216,7 @@ struct mv_udc {
   struct work_struct  vbus_work;
   struct workqueue_struct *qwork;
  
 + struct usb_phy  *phy;
   struct usb_phy  *transceiver;
  
   struct mv_usb_platform_data *pdata;
 diff --git a/drivers/usb/gadget/mv_udc_core.c 
 b/drivers/usb/gadget/mv_udc_core.c
 index c8cf959..4876d2f 100644
 --- a/drivers/usb/gadget/mv_udc_core.c
 +++ b/drivers/usb/gadget/mv_udc_core.c
 @@ -35,6 +35,7 @@
  #include linux/platform_device.h
  #include linux/clk.h
  #include linux/platform_data/mv_usb.h
 +#include linux/usb/mv_usb2.h
  #include asm/unaligned.h
  
  #include mv_udc.h
 @@ -1121,15 +1122,14 @@ static int mv_udc_enable_internal(struct mv_udc *udc)
  
   dev_dbg(udc-dev-dev, enable udc\n);
   udc_clock_enable(udc);
 - if (udc-pdata-phy_init) {
 - retval = udc-pdata-phy_init(udc-phy_regs);
 - if (retval) {
 - dev_err(udc-dev-dev,
 - init phy error %d\n, retval);
 - udc_clock_disable(udc);
 - return retval;
 - }

dude, you really don't test your patches, do you ? Your previous patch
removed -phy_init(), -phy_deinit() and -private_init() from your
platform_data.

Are you seriously telling me you didn't compile test your patches ?

Rewrite your series again and make sure that each and every patch
compiles and works on its own. You shouldn't cause any regressions or
build breaks or build warnings while converting this driver.

I won't review the rest of this series and I'm purging it from my TODO
list.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] USB: storage: fix Huawei mode switching regression

2013-03-04 Thread Ben Hutchings

On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
[...]
 In-kernel mode switching was deprecated years ago with the
 development of the more user friendly userspace alternatives. The
 existing list of devices in usb-storage was only kept to prevent
 breaking already working systems.  The long term plan is to remove
 the list, not to add to it. Ref:
 http://permalink.gmane.org/gmane.linux.usb.general/28543
[...]

Can you add a comment to this effect?

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part

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

Hi,

On Thu, Feb 28, 2013 at 04:13:01PM +0800, Chen Gang wrote:
 
   originally, when deleted the relative code, left some 'another'.
   need delete 'another', too.
   the relative patches are:
 
 commit 96f8db6a77e3490608e5b5b3f57e7201f8c85496
 Author: Felipe Balbi ba...@ti.com
 Date:   Mon Oct 10 10:33:47 2011 +0300
 
   usb: gadget: net2272: convert to new style
 
 
 commit 4cf5e00b055ba5e4f3852e477a2a4346730ea283
 Author: Felipe Balbi ba...@ti.com
 Date:   Mon Oct 10 10:37:17 2011 +0300
 
   usb: gadget: net2280: convert to new style
 
 
 Signed-off-by: Chen Gang gang.c...@asianux.com
 ---
  drivers/usb/gadget/net2272.c |4 
  drivers/usb/gadget/net2280.c |4 
  2 files changed, 0 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/usb/gadget/net2272.c b/drivers/usb/gadget/net2272.c
 index d226058..22ee57c 100644
 --- a/drivers/usb/gadget/net2272.c
 +++ b/drivers/usb/gadget/net2272.c
 @@ -1484,10 +1484,6 @@ stop_activity(struct net2272 *dev, struct 
 usb_gadget_driver *driver)
  {
   int i;
  
 - /* don't disconnect if it's not connected */
 - if (dev-gadget.speed == USB_SPEED_UNKNOWN)
 - driver = NULL;

this is the wrong fix, I believe. Looks like when I wrote the commits
you mention, I deleted more code then I should. Looks like the real fix
would be to add back:

/* report disconnect; the driver is already quiesced */
if (driver) {
spin_unlock(dev-lock);
driver-disconnect(dev-gadget);
spin_lock(dev-lock);
}

since stop_activity() also gets called from RESET interrupt, and in that
case we need to call driver-disconnect(). Can you make a simple test
that would take current code and issue a device reset to see if that
would break, then apply my suggestion above and run the same test again?

If you want, I have a simple libusb-1.0-based little app which can issue
resets to any device you ask. Currently it will reset a device 10K
times but you can remove the for loop if you want:

8--- cut here -


/* $(CROSS_COMPILE)gcc -Wall -O2 -g -lusb-1.0 -o device-reset device-reset.c */
/**
 * device-reset.c - Reset a USB device multiple times
 *
 * Copyright (C) 2013 Felipe Balbi ba...@ti.com
 *
 * This file is part of the USB Verification Tools Project
 *
 * USB Tools is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public Liicense as published by
 * the Free Software Foundation, either version 3 of the license, or
 * (at your option) any later version.
 *
 * USB Tools 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.
 *
 * You should have received a copy of the GNU General Public License
 * along with USB Tools. If not, see http://www.gnu.org/licenses/.
 */

#include stdio.h
#include time.h
#include string.h
#include stdlib.h
#include stdint.h
#include unistd.h
#include fcntl.h
#include ctype.h
#include ctype.h
#include errno.h
#include getopt.h

#include sys/types.h
#include sys/stat.h
#include sys/time.h

#include libusb-1.0/libusb.h

#define OPTION(n, h, v) \
{   \
.name   = #n,   \
.has_arg= h,\
.val= v,\
}

static struct option device_reset_opts[] = {
OPTION(help,  0, 'h'),
OPTION(device,1, 'D'),
{  }/* Terminating entry */
};

static void usage(char *cmd)
{
fprintf(stdout, %s -D VID:PID\n, cmd);
}

int main(int argc, char *argv[])
{
libusb_context  *context;
libusb_device_handle*udevh;

unsignedvid = 0;
unsignedpid = 0;

int ret = 0;
int i;

while (1) {
int optidx;
int opt;

char*token;

opt = getopt_long(argc, argv, D:h, device_reset_opts, 
optidx);
if (opt == -1)
break;

switch (opt) {
case 'D':
token = strtok(optarg, :);
vid = strtoul(token, NULL, 16);
token = strtok(NULL, :);
pid = strtoul(token, NULL, 16);
break;
case 'h': /* FALLTHROUGH */
default:
usage(argv[0]);
exit(-1);
}
}

libusb_init(context);

udevh = libusb_open_device_with_vid_pid(context, vid, pid);
if (!udevh) {
perror(open);
ret = -ENODEV;
goto out0;

Re: [PATCH 3/5] usb: musb: ux500: add otg notifier support

On Thu, Feb 28, 2013 at 11:38:52AM +0100, Fabio Baltieri wrote:
 Add transceiver notifier event handling to the ux500 driver to set vbus
 on specific transceiver events.
 
 Acked-by: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Fabio Baltieri fabio.balti...@linaro.org
 ---
  drivers/usb/musb/ux500.c | 41 +
  1 file changed, 41 insertions(+)
 
 diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
 index 5b742ba..b20326bb 100644
 --- a/drivers/usb/musb/ux500.c
 +++ b/drivers/usb/musb/ux500.c
 @@ -98,6 +98,36 @@ static void ux500_musb_set_vbus(struct musb *musb, int 
 is_on)
   musb_readb(musb-mregs, MUSB_DEVCTL));
  }
  
 +static int musb_otg_notifications(struct notifier_block *nb,
 + unsigned long event, void *unused)
 +{
 + struct musb *musb = container_of(nb, struct musb, nb);
 +
 + dev_dbg(musb-controller, musb_otg_notifications %ld %s\n,
 + event, otg_state_string(musb-xceiv-state));
 +
 + switch (event) {
 + case USB_EVENT_ID:
 + dev_dbg(musb-controller, ID GND\n);
 + ux500_musb_set_vbus(musb, 1);
 + break;
 + case USB_EVENT_VBUS:
 + dev_dbg(musb-controller, VBUS Connect\n);

are you sure this is correct ? you're not doing anything in case of
vbus event. Shouldn't you make sure your vbus is off ? What if your user
uses a non-standard cable which has id-pin grounded on both sides ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH RFC] usb: dwc3: Get PHY from platform specific dwc3 dt node.

Hi,

On Fri, Mar 01, 2013 at 08:41:29AM +0200, Felipe Balbi wrote:
 Moreover, SoCs having multiple dwc3 controllers will have multiple
 PHYs, which eventually be added using usb_add_phy_dev(), and not
 using usb_add_phy(). So each dwc3 controller won't be able to
 get PHYs by simply calling devm_usb_get_phy() also.

 No. We have added usb_get_phy_dev() for that purpose in the case of 
 non-dt.
 I think, instead you can have a patch to use devm_usb_get_phy_dev() 
 here and
 in exynos platform specific code use usb_bind_phy() to bind the phy 
 and
 controller till you change it to dt.

   
We have dt support for dwc3-exynos, in such case we should go ahead 
with
of_platform_populate(), right ?
But if when i use of_platform_populate() i will not be able to set
dma_mask to dwc3-dev. :-(
   
do you have a special need for dma_mask because OF already sets it.
   
   If i am not wrong of_platform_device_create_pdata() will set
   dev-dev.coherent_dma_mask = DMA_BIT_MASK(32)
   and not dma_mask.
   I fact we had some discussion sometime back when we needed the same
   for dwc3-exynos in the thread:
   [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
  
   But couldn't get final node on it.
   So suggestions here please. :-)
  
   hmm.. you're right there. Grant, Rob ? Any hints ?
  
  
  Any suggestions on this ?
 
 anyone ?

ping ?

-- 
balbi


signature.asc
Description: Digital signature

Re: Testing for hardware bug in EHCI controllers

On Mon, 4 Mar 2013, Ming Lei wrote:

 On Tue, Feb 26, 2013 at 4:54 AM, Alan Stern st...@rowland.harvard.edu wrote:
 
 
  I'd be interested to hear the results of testing on a variety of
  controllers.  (This computer also has an NEC EHCI controller, and that
  one does not have the bug.)  Do the EHCI controllers on current Intel
  chipsets pass the test?  What about other vendors?
 
 No the 'EHCI hardware bug detected' error are observed on EHCI
 of OMAP4 pandaboard.

Good; thank you for testing.

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: Testing for hardware bug in EHCI controllers

On Mon, 4 Mar 2013, Bo Shen wrote:

 Hi Alan,
 
 On 02/26/2013 04:54 AM, Alan Stern wrote:
  Sarah (and anyone else who's interested):
 
  A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
  controllers.  You pointed out that these are rather old components, not
  being used in current systems, which is quite true.
 
 I test this on Atmel at91sam9x5ek board with Linux-3.8. And get the 
 similar information. So please indicate me more detail information about 
 the bug. (Sorry for not catch the hardware bug e-mail)

The problem is explained in more detail here:

http://marc.info/?l=linux-usbm=135492071812265w=2

Note that the test program itself requires a small fix, which was 
posted here:

http://marc.info/?l=linux-usbm=136226443502631w=2

If you don't mind, I'd like to see the kernel log from your test run.

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] xhci: correctly enable interrupts

On Mon, 4 Mar 2013, Hannes Reinecke wrote:

 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.

This version of the patch is much better than the first one, IMO.  
Thank you.

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 06/10] usb: xhci: Enable runtime pm in xhci-plat

On Mon, 4 Mar 2013, Vivek Gautam wrote:

  @@ -149,6 +150,8 @@ static int xhci_plat_probe(struct platform_device 
  *pdev)
if (ret)
goto put_usb3_hcd;
 
  + pm_runtime_enable(pdev-dev);
 
  This is generally not a good idea.  You shouldn't enable a device for
  runtime PM without first telling the PM core what state it is in.
 
 Right, but i am not completely sure on any fixed path to follow for
 enabling runtime
 power management on a device. :-(
 Does it become necessary to pm_runtime_set_active or
 pm_runtime_set_suspended a device
 before pm_runtime_enable ?

Yes, it usually is necesary.  And especially here, because the runtime
PM core sets the initial status of every device to RPM_SUSPENDED.

  pm_runtime_enable would just try to
 decrement the disable_depth
 of the device.

That's right.  And once that happens, the PM core would think the 
device was suspended even though it was really at full power.

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 01/10] usb: phy: Add APIs for runtime power management

Hi,

On Sat, Mar 02, 2013 at 06:53:02PM +0530, Vivek Gautam wrote:
 Adding  APIs to handle runtime power management on PHY
 devices. PHY consumers may need to wake-up/suspend PHYs
 when they work across autosuspend.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  include/linux/usb/phy.h |   26 ++
  1 files changed, 26 insertions(+), 0 deletions(-)
 
 diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
 index 15847cb..0fe7cac 100644
 --- a/include/linux/usb/phy.h
 +++ b/include/linux/usb/phy.h
 @@ -276,4 +276,30 @@ static inline const char *usb_phy_type_string(enum 
 usb_phy_type type)
   return UNKNOWN PHY TYPE;
   }
  }
 +
 +#define USB_PHY_AUTOPM(function) \
 +static inline int usb_phy_autopm_##function(struct usb_phy *x)   
 \
 +{\
 + if (!x || !x-dev) {\
 + dev_err(x-dev, no PHY or attached device available\n);   \
 + return -ENODEV; \
 + }   \
 + \
 + pm_runtime_##function(x-dev);  \

please make the definitions explicit (not using a macro) and use:

return pm_runtime_foo();

where applicable. We don't want to return 0 if pm_runtime_get_sync()
fails.

-- 
balbi


signature.asc
Description: Digital signature

Re: Testing for hardware bug in EHCI controllers

On Mon, 4 Mar 2013, Lan Tianyu wrote:

 Test on the Sandybridge platform.
 At the first time, I get following output. But after that, I was
 hard to get any output. And test on the v3.8.

You have to unplug the flash drive after running the test each time. 
By the way, be sure to apply Clemens Ladisch's fix to the test program:

http://marc.info/?l=linux-usbm=136226443502631w=2

 sudo ./ehci-test /dev/bus/usb/001/003
 [  140.855342] usb-storage 1-1.2:1.0: disconnect by usbfs
 Invalid URB stat[  140.863000] ehci-pci :00:1a.0: shutdown urb
 88014545f300 ep1in-bulk
 [  140.871303] ehci-pci :00:1a.0: shutdown urb 88014545f0c0 ep1in-bulk
 [  140.878231] ehci-pci :00:1a.0: shutdown urb 88014545fcc0 ep1in-bulk
 [  140.885158] ehci-pci :00:1a.0: shutdown urb 88014545fb40 ep1in-bulk
 [  140.892088] ehci-pci :00:1a.0: shutdown urb 88014545f9c0 ep1in-bulk
 [  140.899015] ehci-pci :00:1a.0: shutdown urb 88014545f780 ep1in-bulk
 [  140.905941] ehci-pci :00:1a.0: shutdown urb 88014545f240 ep1in-bulk
 [  140.912870] ehci-pci :00:1a.0: shutdown urb 88014545f900 ep1in-bulk
 [  140.919799] ehci-pci :00:1a.0: shutdown urb 88014545fc00 ep1in-bulk
 [  140.926725] ehci-pci :00:1a.0: shutdown urb 88014545f540 ep1in-bulk
 [  140.933655] ehci-pci :00:1a.0: shutdown urb 88014545f3c0 ep1in-bulk
 [  140.940583] ehci-pci :00:1a.0: shutdown urb 88014545fd80 ep1in-bulk
 [  140.947512] ehci-pci :00:1a.0: shutdown urb 88014545f600 ep1in-bulk
 [  140.954440] ehci-pci :00:1a.0: shutdown urb 88014545f180 ep1in-bulk
 [  140.961368] ehci-pci :00:1a.0: shutdown urb 88014545f000 ep1in-bulk
 [  140.968297] ehci-pci :00:1a.0: shutdown urb 88014545fa80 ep1in-bulk
 [  140.975223] ehci-pci :00:1a.0: shutdown urb 88014545f840 ep1in-bulk
 us -32, act len [  140.982151] ehci-pci :00:1a.0: shutdown urb
 88014545fe40 ep1in-bulk
 [  140.990459] ehci-pci :00:1a.0: shutdown urb 88014545ff00 ep1in-bulk
 [  140.997388] ehci-pci :00:1a.0: shutdown urb 880145f08000 ep1in-bulk
 [  141.004316] ehci-pci :00:1a.0: shutdown urb 880145f080c0 ep1in-bulk
 [  141.011245] ehci-pci :00:1a.0: shutdown urb 880145f08180 ep1in-bulk

The fix to the test program ought to help with this.

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 06/10] usb: xhci: Enable runtime pm in xhci-plat

On Sun, 3 Mar 2013, Felipe Balbi wrote:

   this is good point and, in fact, a doubt I have myself. How are we
   supposed to check if device is suspended ? In case it _is_ suspended we
   might not be able to read device's registers due to clocks possibly
   being gated.
  
  That's really a separate question.  It has a simple answer, though: If 
  you want to access a device's registers, call pm_runtime_get_sync() 
  beforehand and pm_runtime_put() (or _put_sync()) afterward.  Then it 
  won't matter if the device was suspended originally.
 
 that's alright, but how do you want me to check if my device is enabled
 or not before pm_runtime_enable() ?

You're not supposed to check.  Just make sure your own 
pm_runtime_enable() and _disable() calls are done correctly, and let 
the PM core worry about the rest.  :-)

More to the point, the question of what code enables a device for
runtime PM is decided by the subsystem.  Many subsystems will do it
automatically so that their drivers don't have to worry about it.  
Other subsystems will leave it entirely up to the drivers.  You have to
know what the subsystem wants.

In this case, it's appropriate to do the enable here in the probe
routine because the platform core doesn't do it for you.  This also
means the driver should disable the device in the remove routine.

  I don't know much about clock handling.  In general, the
  pm_runtime_set_active() and pm_runtime_enable() parts should be done by
  the subsystem, not the driver, whenever possible.
 
 good to know :-) Though I disagree with calling pm_runtime_enable() at
 the subsystem level.

It depends on the subsystem.  For some (like the USB host subsystem),
it is appropriate.

  Whichever piece of code is responsible for associating a clock with a
  device should also be responsible for making sure that neither is
  suspended when the driver's probe routine runs.  I'm not sure how 
  different platforms do this; using a PM domain could be one answer.
 
 that's alright, but it generates a different set of problems. That same
 piece of code which associates a device with its clock, doesn't really
 know if the driver is even available which means we could be enabling
 clocks for no reason and just wasting precious battery juice ;-)

Better than wasting our precious bodily fluids...  :-)

I guess the best answer is to set up the association but then leave the
device and clocks in a runtime-suspended status.  Then do a
pm_runtime_get_sync() just before calling the driver's probe routine
and a pm_runtime_put_sync() just after calling the remove routine.  
That should leave the device and the clocks in the state the driver
expects.  (But be careful that these two calls don't invoke the
driver's runtime-PM callbacks!)

Probably nobody has thought these problems through very carefully for 
the platform subsystem.  Nevertheless, that's where the decisions need 
to be made.

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] xhci: correctly enable interrupts

2013-03-04 Thread Thomas Renninger

On Monday, March 04, 2013 10:26:40 AM Alan Stern wrote:
 On Mon, 4 Mar 2013, Hannes Reinecke wrote:
  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.
 
 This version of the patch is much better than the first one, IMO.

I also have this issue. Unfortunately pci read only gives an irq of 255
in secure boot mode and I don't want to struggle with kernel/module
signing to test this.

I found one issue with this patch:
For xhci legacy PCI is not tried to be set up now anymore (before MSI(x)
is tried) which is a correct fix.

But in xhci_try_enable_msi() drivers/usb/host/xhci.c if MSI is known broken
(xhci-quirks  XHCI_BROKEN_MSI), it relies on legacy IRQ being enabled
already.
Instead it should use the enable legacy IRQ code later in the same function 
which is the fallback if MSI setup does not succeed.

I send an updated version taking care about above and including the do not 
split string concern Sergei mentioned.

Thomas
--
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][v3] xhci: correctly enable interrupts

2013-03-04 Thread Thomas Renninger

From: Hannes Reinecke h...@suse.de

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 bhelg...@google.com
Cc: Oliver Neukum oneu...@suse.de
Cc: Thomas Renninger tr...@suse.de
Cc: Yinghai Lu ying...@kernel.org
Cc: Frederik Himpe fhi...@vub.ac.be
Cc: David Haerdeman da...@hardeman.nu
Cc: Alan Stern st...@rowland.harvard.edu

Reviewed-by: Thomas Renninger tr...@suse.de
Signed-off-by: Hannes Reinecke h...@suse.de

diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 622b4a4..2b487d4 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -173,6 +173,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
struct hc_driver*driver;
struct usb_hcd  *hcd;
int retval;
+   int hcd_irq = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -187,15 +188,19 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return -ENODEV;
dev-current_state = PCI_D0;
 
-   /* The xHCI driver supports MSI and MSI-X,
-* so don't fail if the BIOS doesn't provide a legacy IRQ.
+   /*
+* The xHCI driver has its own irq management
+* make sure irq setup is not touched for xhci in generic hcd code
 */
-   if (!dev-irq  (driver-flags  HCD_MASK) != HCD_USB3) {
-   dev_err(dev-dev,
-   Found HC with no IRQ.  Check BIOS/PCI %s setup!\n,
-   pci_name(dev));
-   retval = -ENODEV;
-   goto disable_pci;
+   if ((driver-flags  HCD_MASK) != HCD_USB3) {
+   if (!dev-irq) {
+   dev_err(dev-dev,
+   Found HC with no IRQ. Check BIOS/PCI %s setup!\n,
+   pci_name(dev));
+   retval = -ENODEV;
+   goto disable_pci;
+   }
+   hcd_irq = dev-irq;
}
 
hcd = usb_create_hcd(driver, dev-dev, pci_name(dev));
@@ -245,7 +250,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
 
pci_set_master(dev);
 
-   retval = usb_add_hcd(hcd, dev-irq, IRQF_SHARED);
+   retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
if (retval != 0)
goto unmap_registers;
set_hs_companion(dev, hcd);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f1f01a8..849470b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -350,7 +350,7 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
 * generate interrupts.  Don't even try to enable MSI.
 */
if (xhci-quirks  XHCI_BROKEN_MSI)
-   return 0;
+   goto legacy_irq;
 
/* unregister the legacy interrupt */
if (hcd-irq)
@@ -371,6 +371,7 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
return -EINVAL;
}
 
+ legacy_irq:
/* fall back to legacy interrupt*/
ret = request_irq(pdev-irq, usb_hcd_irq, IRQF_SHARED,
hcd-irq_descr, hcd);

--
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: storage: fix Huawei mode switching regression

Ben Hutchings b...@decadent.org.uk writes:
 On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
 [...]
 In-kernel mode switching was deprecated years ago with the
 development of the more user friendly userspace alternatives. The
 existing list of devices in usb-storage was only kept to prevent
 breaking already working systems.  The long term plan is to remove
 the list, not to add to it. Ref:
 http://permalink.gmane.org/gmane.linux.usb.general/28543
 [...]

 Can you add a comment to this effect?

In the table in unusual_devs.h, you mean?  Sure, I can do that.

But it feels a bit strange since I can only quote and/or refer to what
Matthew and Greg said about the issue years ago.  Putting a comment in
the code to remind the current maintainers about their own statements
could be considered out of line?  Or is this appropriate here?


Bjørn
--
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: host: tegra: Reset Tegra USB controller before init

2013-03-04 Thread Stephen Warren

On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
 Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
 On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
 To clear any configurations made by U-Boot on Tegra USB controller,
 reset it before init in probe.

 diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c

 @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device
 *pdev)
 if (err)
 goto fail_clk;

 +   tegra_periph_reset_assert(tegra-clk);
 +   udelay(1);
 +   tegra_periph_reset_deassert(tegra-clk);

 I think this patch might cause unintended consequences.

 When the Tegra PHY code is converted to a driver (i.e. has its own
 probe), the initial order of execution of the PHY and EHCI driver probes
 will not be guaranteed.

 In particular, since the EHCI probe will attempt to find the PHY
 device, and defer the EHCI probe until it can do so, this guarantees
 that the PHY's probe() will have completed before EHCI's probe()
 completes (although EHCI's probe may start running first some number of
 times, and be retried with -EPROBE_DEFERRED for a variety of reasons).

 Now, if the PHY driver's probe() actually touches HW and sets up some
 registers, isn't this reset call going to trash any of that register
 setup? Or, will PHY probe() not touch registers, but only do so during
 the standard PHY open/init op/API calls?
  
 Yes, PHY driver probe does not touch any registers. It just sets up the PHY 
 API hooks.
 These APIs will be called from ehci-tegra.c as part of ehci tegra probe 
 function, after
 getting  PHY handle, which in turn happens after issuing above reset.
 
 Thanks to Stephen  Alan, for the review comments.

OK, in that case I have no objection to this patch.

I'd like to hold off on applying this though; I suspect I'll want to
take the Tegra USB patches through the Tegra tree rather than the USB
tree again for the 3.10 kernel cycle. I think I may have screwed the
pooch on the DT binding I set up for the USB controller clocks, and
fixing this may require some Tegra DT changes, which would be easiest
taken through the Tegra tree, and so to reduce conflicts in the USB
code, taking the rest through there migth just be easiest.

Alan, Greg, if you're OK with this patch now, or for any revised
version, an Ack so I can take it through the Tegra tree would be great,
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: [PATCH] USB: storage: fix Huawei mode switching regression

2013-03-04 Thread Matthew Dharm

Frankly, I consider it appropriate.

The question is not one of reminding me of what I said earlier
it's one of pointing people in the right direction.  Frankly, some of
the fault for this patch lies with Greg and myself for letting it
through.  I had just assumed that the Huawei guys had already been in
touch with usb-modeswitch for some reason, and that this was just an
optimization of existing logic (not an expansion).  And, frankly, I
was just a bit tired of fighting this fight over and over again;
having something in the file which says here's the right and official
way to do this would be good.

I also asked the Huawei guys about the possibility of affecting other
devices than the one listed I guess one of us either wasn't clear
or mis-understood the request.  The fact that there are devices out
there failing now illustrates that.  Avoiding breaking existing
systems is one of the highest priorities

Who is maintaining usb-modeswitch these days, anyway?  The comment in
the file should point people directly there

And, as of now, I would really like to see as many of these devices
migrated (albeit slowly) to using usb-modeswitch wherever possible.  I
know there are a few devices for which that might not be possible, but
I am DONE dealing with this same issue over and over and over again.
It will certainly be work to migrate support; maybe we should wrap all
the relevant unusual_devs.h entires with
CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a
transition period?

Matt



On Mon, Mar 4, 2013 at 8:47 AM, Bjørn Mork bj...@mork.no wrote:
 Ben Hutchings b...@decadent.org.uk writes:
 On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
 [...]
 In-kernel mode switching was deprecated years ago with the
 development of the more user friendly userspace alternatives. The
 existing list of devices in usb-storage was only kept to prevent
 breaking already working systems.  The long term plan is to remove
 the list, not to add to it. Ref:
 http://permalink.gmane.org/gmane.linux.usb.general/28543
 [...]

 Can you add a comment to this effect?

 In the table in unusual_devs.h, you mean?  Sure, I can do that.

 But it feels a bit strange since I can only quote and/or refer to what
 Matthew and Greg said about the issue years ago.  Putting a comment in
 the code to remind the current maintainers about their own statements
 could be considered out of line?  Or is this appropriate here?


 Bjørn



--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
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

2013-03-04 Thread Sergei Shtylyov


Hello.

On 03/04/2013 07:14 PM, Thomas Renninger wrote:


From: Hannes Reineckeh...@suse.de

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 Helgaasbhelg...@google.com
Cc: Oliver Neukumoneu...@suse.de
Cc: Thomas Renningertr...@suse.de
Cc: Yinghai Luying...@kernel.org
Cc: Frederik Himpefhi...@vub.ac.be
Cc: David Haerdemanda...@hardeman.nu
Cc: Alan Sternst...@rowland.harvard.edu

Reviewed-by: Thomas Renningertr...@suse.de
Signed-off-by: Hannes Reineckeh...@suse.de

   Still a couple of style comments...

[...]


@@ -187,15 +188,19 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return -ENODEV;
dev-current_state = PCI_D0;

-   /* The xHCI driver supports MSI and MSI-X,
-* so don't fail if the BIOS doesn't provide a legacy IRQ.
+   /*
+* The xHCI driver has its own irq management
+* make sure irq setup is not touched for xhci in generic hcd code
 */
-   if (!dev-irq  (driver-flags  HCD_MASK) != HCD_USB3) {
-   dev_err(dev-dev,
-   Found HC with no IRQ.  Check BIOS/PCI %s setup!\n,
-   pci_name(dev));
-   retval = -ENODEV;
-   goto disable_pci;
+   if ((driver-flags  HCD_MASK) != HCD_USB3) {
+   if (!dev-irq) {
+   dev_err(dev-dev,
+   Found HC with no IRQ. Check BIOS/PCI %s setup!\n,
   


   Could you indent the string like the line below?


+   pci_name(dev));
+   retval = -ENODEV;
+   goto disable_pci;
+   }
+   hcd_irq = dev-irq;
}

hcd = usb_create_hcd(driver,dev-dev, pci_name(dev));
   

[...]

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f1f01a8..849470b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
   

[...]

@@ -371,6 +371,7 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
return -EINVAL;
}

+ legacy_irq:
   


   Labels shouldn't be indented by a space (unless the existing coding 
style has them indented already, of course).
Although that might be a rule dropped by checkpatch.pl already -- it 
doesn't complain.


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: [PATCH][v3] xhci: correctly enable interrupts

On Mon, 4 Mar 2013, Sergei Shtylyov wrote:

  @@ -371,6 +371,7 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
  return -EINVAL;
  }
 
  + legacy_irq:
 
 
 Labels shouldn't be indented by a space (unless the existing coding 
 style has them indented already, of course).
 Although that might be a rule dropped by checkpatch.pl already -- it 
 doesn't complain.

Indeed, there's a definite advantage to putting a space before a label:  
The diff program doesn't get confused into thinking the label is the
start of a new function.

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] usb: host: tegra: Reset Tegra USB controller before init

On Mon, 4 Mar 2013, Stephen Warren wrote:

 On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
  Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
  On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
  To clear any configurations made by U-Boot on Tegra USB controller,
  reset it before init in probe.
 
  diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
 
  @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device
  *pdev)
if (err)
goto fail_clk;
 
  + tegra_periph_reset_assert(tegra-clk);
  + udelay(1);
  + tegra_periph_reset_deassert(tegra-clk);

 OK, in that case I have no objection to this patch.
 
 I'd like to hold off on applying this though; I suspect I'll want to
 take the Tegra USB patches through the Tegra tree rather than the USB
 tree again for the 3.10 kernel cycle. I think I may have screwed the
 pooch on the DT binding I set up for the USB controller clocks, and
 fixing this may require some Tegra DT changes, which would be easiest
 taken through the Tegra tree, and so to reduce conflicts in the USB
 code, taking the rest through there migth just be easiest.
 
 Alan, Greg, if you're OK with this patch now, or for any revised
 version, an Ack so I can take it through the Tegra tree would be great,
 thanks.

I have no other objections.

Acked-by: Alan Stern st...@rowland.harvard.edu

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: Testing for hardware bug in EHCI controllers

2013-03-04 Thread Frank Schäfer

Am 25.02.2013 21:54, schrieb Alan Stern:
 Sarah (and anyone else who's interested):

 A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
 controllers.  You pointed out that these are rather old components, not 
 being used in current systems, which is quite true.

 Now I have figured out a simple way for anyone to test for this bug in
 any EHCI controller, without the need for a g-zero gadget.  It's a
 two-part procedure:

   Apply the patch below (which is written for vanilla 3.8) and
   load the resulting driver.  The patch adds an explicit test
   to ehci-hcd for detecting the bug.

   Then plug in an ordinary USB flash drive and run the attached
   program (as root), giving it the device path for the flash
   drive as the single command-line argument.  For example:

   sudo ./ehci-test /dev/bus/usb/002/003

 The program won't do anything bad to the flash drive; it just reads the
 first 256 KB of data over and over again, now and then unlinking an URB
 to try and trigger the bug.  If the program works right, it will print
 out a loop counter every hundred iterations.  If it runs for 1000
 iterations with no error messages in the kernel log, you may consider
 that the controller has passed the test.  This should take under a
 minute, depending on the hardware speed.

 The program won't stop by itself unless something goes wrong.  You can
 kill it with ^C or more simply by unplugging the flash drive.  (If you
 want to be safe, make sure there are no mounted filesystems on the
 drive before running the test program.)

 If the hardware bug is detected, the kernel patch will print error
 messages to the system log.  For example, when I run the test on the
 Intel controller in this computer, I get:

 [  150.019441] usb-storage 3-8:1.0: disconnect by usbfs
 [  150.271190] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  150.591089] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  151.538560] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  151.857569] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  152.018886] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  152.179810] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  153.211804] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  153.374497] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  153.770443] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  154.247861] ehci-pci :00:1d.7: EHCI hardware bug detected: 82008d80 
 8d00
 [  154.566912] ehci-pci :00:1d.7: EHCI hardware bug detected: 82008d80 
 8d00
 [  155.359101] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  155.838132] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  156.791107] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  157.267620] ehci-pci :00:1d.7: EHCI hardware bug detected: 8d00 
 80008d00
 [  159.252057] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  159.886048] ehci-pci :00:1d.7: EHCI hardware bug detected: 80008d00 
 8d00
 [  160.206625] ehci-pci :00:1d.7: EHCI hardware bug detected: 02008d80 
 80008d00
 ...

 You get the idea.  The values in the two columns on the right are 
 always supposed to be equal; when they aren't it indicates that the 
 controller has done a DMA write at a time when ehci-hcd isn't expecting 
 one to happen.

 I'd be interested to hear the results of testing on a variety of 
 controllers.  (This computer also has an NEC EHCI controller, and that 
 one does not have the bug.)  Do the EHCI controllers on current Intel 
 chipsets pass the test?  What about other vendors?

 Thanks to all who try it out and report their results.

 Alan Stern

Here is the result of your test procedure (fix applied, running kernel
3.9-rc1) for the following device:

00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0
Controller [10de:03f2] (rev a2) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Device [1043:8234]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 22
Region 0: Memory at fe02e000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci-pci


= dmesg output:
[  207.965961] ehci-pci

Re: Testing for hardware bug in EHCI controllers

On Mon, 4 Mar 2013, [ISO-8859-1] Frank Sch�fer wrote:

 Here is the result of your test procedure (fix applied, running kernel
 3.9-rc1) for the following device:
 
 00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0
 Controller [10de:03f2] (rev a2) (prog-if 20 [EHCI])
 Subsystem: ASUSTeK Computer Inc. Device [1043:8234]

 = dmesg output:
 [  207.965961] ehci-pci :00:02.1: EHCI hardware bug detected:
 80008d00 8d00
 [  208.020904] ehci-pci :00:02.1: EHCI hardware bug detected:
 82008d80 8d00
 [  208.198698] ehci-pci :00:02.1: EHCI hardware bug detected:
 80008d00 9d00
 [  208.201699] ehci-pci :00:02.1: EHCI hardware bug detected:
 82008d80 9d00

So NVIDIA hardware has the same bug as Intel.  That's good to know; I 
was starting to think no other vendors would be affected.  Thanks.

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 3.8-stable] usbnet: smsc95xx: fix suspend failure

2013-03-04 Thread David Miller

From: Ming Lei ming@canonical.com
Date: Mon,  4 Mar 2013 18:07:13 +0800

 The three below functions:
 
 smsc95xx_enter_suspend0()
 smsc95xx_enter_suspend1()
 smsc95xx_enter_suspend2()
 
 return  0 in case of success, so they will cause smsc95xx_suspend()
 to return  0 and suspend failure.
 
 This patch is backported from the upstream commit:
 
   From 7643721471117d5f62ca36f328d3dc8d84af4402 Mon Sep 17 00:00:00 2001
   Subject: [PATCH] usbnet: smsc95xx: fix suspend failure
 
 Cc: sta...@vger.kernel.org
 Cc: Steve Glendinning steve.glendinn...@shawell.net
 Signed-off-by: Ming Lei ming@canonical.com

This is fine, Greg please apply to 3.8-stable, 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: [PATCH] USB: storage: fix Huawei mode switching regression

Matthew Dharm mdharm-...@one-eyed-alien.net writes:

 Frankly, I consider it appropriate.

OK, I'll try to cook something up.

 The question is not one of reminding me of what I said earlier
 it's one of pointing people in the right direction.  Frankly, some of
 the fault for this patch lies with Greg and myself for letting it
 through.  I had just assumed that the Huawei guys had already been in
 touch with usb-modeswitch for some reason, and that this was just an
 optimization of existing logic (not an expansion).  And, frankly, I
 was just a bit tired of fighting this fight over and over again;
 having something in the file which says here's the right and official
 way to do this would be good.

 I also asked the Huawei guys about the possibility of affecting other
 devices than the one listed I guess one of us either wasn't clear
 or mis-understood the request.  The fact that there are devices out
 there failing now illustrates that.  Avoiding breaking existing
 systems is one of the highest priorities

Well, I am a bit embarrassed by this.  I did notice the patch and even
looked through it when it was posted.  But when I later noticed the
switching failure I didn't think more about it at all.  I just put the
error on my to-be-investigated-further list.  Which tends to erase
itself before I get to it...

 Who is maintaining usb-modeswitch these days, anyway?  The comment in
 the file should point people directly there

That would be Josua Dietze, who I intended to CC from the beginning of
this discussion but forgot...  Sorry about that.  I'm certainly not
going to complain about anyone else forgetting stuff :)

CCed now. Josh, I assume it's OK for you if we put a pointer to
http://www.draisberghof.de/usb_modeswitch/ in the unusual_devs.h code? 

 And, as of now, I would really like to see as many of these devices
 migrated (albeit slowly) to using usb-modeswitch wherever possible.  I
 know there are a few devices for which that might not be possible, but
 I am DONE dealing with this same issue over and over and over again.
 It will certainly be work to migrate support; maybe we should wrap all
 the relevant unusual_devs.h entires with
 CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a
 transition period?

Sounds good to me, if that is acceptable to the user interface stability
committee.

I guess the real problem will be verifying that all of the entries *can*
go away. This type of hardware tends to get old very fast, but there is
always someone having a really ancient device.

Maybe we could use the same method the netdev people use when they want
to remove stuff: Subtly break it and leave it like that for a few years
before finally deleting it, arguing that noone can be using the feature
because it's broken :)


Bjørn

 On Mon, Mar 4, 2013 at 8:47 AM, Bjørn Mork bj...@mork.no wrote:
 Ben Hutchings b...@decadent.org.uk writes:
 On Mon, 2013-03-04 at 14:19 +0100, Bjørn Mork wrote:
 [...]
 In-kernel mode switching was deprecated years ago with the
 development of the more user friendly userspace alternatives. The
 existing list of devices in usb-storage was only kept to prevent
 breaking already working systems.  The long term plan is to remove
 the list, not to add to it. Ref:
 http://permalink.gmane.org/gmane.linux.usb.general/28543
 [...]

 Can you add a comment to this effect?

 In the table in unusual_devs.h, you mean?  Sure, I can do that.

 But it feels a bit strange since I can only quote and/or refer to what
 Matthew and Greg said about the issue years ago.  Putting a comment in
 the code to remind the current maintainers about their own statements
 could be considered out of line?  Or is this appropriate here?


 Bjørn



 --
 Matthew Dharm
 Maintainer, USB Mass Storage driver for Linux
 --
 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
--
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 v6 0/7] DWC2 DesignWare HS OTG driver

Hi Greg,

Here is the latest version of the DWC2 patch set. This version includes
changes suggested by Felipe in his last review, plus a couple of changes
requested by Alan Stern.

Please consider applying these to usb-next. Felipe thought these should
go in through your tree, since they don't contain any gadget-related
code (yet). Thanks.

-- 
Paul


This is a host-mode driver for the Synopsys DesignWare HS OTG controller. 
This is the same controller whose peripheral mode is implemented by the
existing s3c-hsotg driver. This controller is also used in host mode in the
Raspberry Pi via a very ugly out-of-tree driver, so merging this would be a
step toward bringing USB support for that platform into mainline.

The idea is to add a dwc2/ directory alongside the existing dwc3/ directory,
initially to contain just this host-mode driver. Once that has been accepted
we would then like to move the s3c-hsotg driver into this directory and
integrate it to make a dual-role driver. Finally we will implement support
for the OTG features of the controller.

This driver is still a work in progress, to wit:

- Only a PCI bus interface has been implemented so far. However the core
  code and the PCI bus glue code are contained in separate modules, so it
  will be easy to add platform driver interfaces in the future. I have
  already done that with a platform driver for the Raspberry Pi, but it
  is not included here since USB support for that platform is out of tree.

- There is no power-management support yet.

- There is quite a bit of debug code included. We would like to keep that
  until the integration with s3c-hsotg is complete, then most of it can be
  stripped out.

Changes since v5 - Made a few minor tweaks in response to Felipe's last
review. Also, use usb_calc_bus_time() in place of a private version,
and implement the .clear_tt_buffer_complete callback, both at the
suggestion of Alan Stern. Fixed a couple of driver crashes that were
exposed by those changes.

Changes since v4 - Changes in response to Felipe's third review. Also
removed the module parameters. Plus made a few more cleanups and
simplifications.

Changes since v3 - Numerous changes in response to Felipe's second review.

Changes since v2 - Fixed a problem with periodic transfers, so hubs, mice
and keyboards work reliably now. Fixed a spurious channel halted interrupt
by disabling the interrupt if the channel is idle.

Changes since v1 - Numerous changes in response to Felipe's review.

Paul Zimmerman (7):
  usb: common: add a routine to print the OTG state
  Core files for the DWC2 driver
  HCD files for the DWC2 driver
  HCD descriptor DMA support for the DWC2 driver
  PCI bus interface for the DWC2 driver
  Hook the DWC2 driver into the build system
  Add a MAINTAINERS entry for the DWC2 driver

 MAINTAINERS  |6 +
 drivers/usb/Kconfig  |2 +
 drivers/usb/Makefile |2 +
 drivers/usb/dwc2/Kconfig |   41 +
 drivers/usb/dwc2/Makefile|   23 +
 drivers/usb/dwc2/core.c  | 2678 ++
 drivers/usb/dwc2/core.h  |  658 ++
 drivers/usb/dwc2/core_intr.c |  483 +++
 drivers/usb/dwc2/hcd.c   | 2890 ++
 drivers/usb/dwc2/hcd.h   |  749 +++
 drivers/usb/dwc2/hcd_ddma.c  | 1183 +
 drivers/usb/dwc2/hcd_intr.c  | 2095 ++
 drivers/usb/dwc2/hcd_queue.c |  690 ++
 drivers/usb/dwc2/hw.h|  811 
 drivers/usb/dwc2/pci.c   |  198 +++
 drivers/usb/usb-common.c |   26 +
 include/linux/usb/phy.h  |8 +
 17 files changed, 12543 insertions(+)
 create mode 100644 drivers/usb/dwc2/Kconfig
 create mode 100644 drivers/usb/dwc2/Makefile
 create mode 100644 drivers/usb/dwc2/core.c
 create mode 100644 drivers/usb/dwc2/core.h
 create mode 100644 drivers/usb/dwc2/core_intr.c
 create mode 100644 drivers/usb/dwc2/hcd.c
 create mode 100644 drivers/usb/dwc2/hcd.h
 create mode 100644 drivers/usb/dwc2/hcd_ddma.c
 create mode 100644 drivers/usb/dwc2/hcd_intr.c
 create mode 100644 drivers/usb/dwc2/hcd_queue.c
 create mode 100644 drivers/usb/dwc2/hw.h
 create mode 100644 drivers/usb/dwc2/pci.c

-- 
1.8.2.rc0.16.g20a599e

--
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 v6 1/7] usb: common: add a routine to print the OTG state

Add a usb_otg_state_string() routine to print the OTG state for
debugging

Signed-off-by: Paul Zimmerman pa...@synopsys.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/usb-common.c | 26 ++
 include/linux/usb/phy.h  |  8 
 2 files changed, 34 insertions(+)

diff --git a/drivers/usb/usb-common.c b/drivers/usb/usb-common.c
index d29503e..33daf2a 100644
--- a/drivers/usb/usb-common.c
+++ b/drivers/usb/usb-common.c
@@ -14,6 +14,7 @@
 #include linux/kernel.h
 #include linux/module.h
 #include linux/usb/ch9.h
+#include linux/usb/phy.h
 
 const char *usb_speed_string(enum usb_device_speed speed)
 {
@@ -32,4 +33,29 @@ const char *usb_speed_string(enum usb_device_speed speed)
 }
 EXPORT_SYMBOL_GPL(usb_speed_string);
 
+const char *usb_otg_state_string(enum usb_otg_state state)
+{
+   static const char *const names[] = {
+   [OTG_STATE_UNDEFINED] = UNDEFINED,
+   [OTG_STATE_B_IDLE] = b_idle,
+   [OTG_STATE_B_SRP_INIT] = b_srp_init,
+   [OTG_STATE_B_PERIPHERAL] = b_peripheral,
+   [OTG_STATE_B_WAIT_ACON] = b_wait_acon,
+   [OTG_STATE_B_HOST] = b_host,
+   [OTG_STATE_A_IDLE] = a_idle,
+   [OTG_STATE_A_WAIT_VRISE] = a_wait_vrise,
+   [OTG_STATE_A_WAIT_BCON] = a_wait_bcon,
+   [OTG_STATE_A_HOST] = a_host,
+   [OTG_STATE_A_SUSPEND] = a_suspend,
+   [OTG_STATE_A_PERIPHERAL] = a_peripheral,
+   [OTG_STATE_A_WAIT_VFALL] = a_wait_vfall,
+   [OTG_STATE_A_VBUS_ERR] = a_vbus_err,
+   };
+
+   if (state  0 || state = ARRAY_SIZE(names))
+   state = OTG_STATE_UNDEFINED;
+   return names[state];
+}
+EXPORT_SYMBOL_GPL(usb_otg_state_string);
+
 MODULE_LICENSE(GPL);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 15847cb..e150155 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -276,4 +276,12 @@ static inline const char *usb_phy_type_string(enum 
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
 }
+
+/**
+ * usb_otg_state_string() - Returns human readable-name of the OTG state.
+ * @state: The state to return human-readable name for.  If it's not
+ *   any of the states defined in usb_otg_state enum, string for
+ *   OTG_STATE_UNDEFINED will be returned.
+ */
+extern const char *usb_otg_state_string(enum usb_otg_state state);
 #endif /* __LINUX_USB_PHY_H */
-- 
1.8.2.rc0.16.g20a599e

--
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 v6 4/7] HCD descriptor DMA support for the DWC2 driver

This file contains code to support the HCD descriptor DMA mode of
the controller

Signed-off-by: Paul Zimmerman pa...@synopsys.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/dwc2/hcd_ddma.c | 1183 +++
 1 file changed, 1183 insertions(+)
 create mode 100644 drivers/usb/dwc2/hcd_ddma.c

diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
new file mode 100644
index 000..2f602f7
--- /dev/null
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -0,0 +1,1183 @@
+/*
+ * hcd_ddma.c - DesignWare HS OTG Controller descriptor DMA routines
+ *
+ * Copyright (C) 2004-2013 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
+ * IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * This file contains the Descriptor DMA implementation for Host mode
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/usb.h
+
+#include linux/usb/hcd.h
+#include linux/usb/ch11.h
+
+#include core.h
+#include hcd.h
+
+static u16 dwc2_frame_list_idx(u16 frame)
+{
+   return frame  (FRLISTEN_64_SIZE - 1);
+}
+
+static u16 dwc2_desclist_idx_inc(u16 idx, u16 inc, u8 speed)
+{
+   return (idx + inc) 
+   ((speed == USB_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 dwc2_desclist_idx_dec(u16 idx, u16 inc, u8 speed)
+{
+   return (idx - inc) 
+   ((speed == USB_SPEED_HIGH ? MAX_DMA_DESC_NUM_HS_ISOC :
+ MAX_DMA_DESC_NUM_GENERIC) - 1);
+}
+
+static u16 dwc2_max_desc_num(struct dwc2_qh *qh)
+{
+   return (qh-ep_type == USB_ENDPOINT_XFER_ISOC 
+   qh-dev_speed == USB_SPEED_HIGH) ?
+   MAX_DMA_DESC_NUM_HS_ISOC : MAX_DMA_DESC_NUM_GENERIC;
+}
+
+static u16 dwc2_frame_incr_val(struct dwc2_qh *qh)
+{
+   return qh-dev_speed == USB_SPEED_HIGH ?
+  (qh-interval + 8 - 1) / 8 : qh-interval;
+}
+
+static int dwc2_desc_list_alloc(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh,
+   gfp_t flags)
+{
+   qh-desc_list = dma_alloc_coherent(hsotg-dev,
+   sizeof(struct dwc2_hcd_dma_desc) *
+   dwc2_max_desc_num(qh), qh-desc_list_dma,
+   flags);
+
+   if (!qh-desc_list)
+   return -ENOMEM;
+
+   memset(qh-desc_list, 0,
+  sizeof(struct dwc2_hcd_dma_desc) * dwc2_max_desc_num(qh));
+
+   qh-n_bytes = kzalloc(sizeof(u32) * dwc2_max_desc_num(qh), flags);
+   if (!qh-n_bytes) {
+   dma_free_coherent(hsotg-dev, sizeof(struct dwc2_hcd_dma_desc)
+ * dwc2_max_desc_num(qh), qh-desc_list,
+ qh-desc_list_dma);
+   qh-desc_list = NULL;
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+static void dwc2_desc_list_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh)
+{
+   if (qh-desc_list) {
+   dma_free_coherent(hsotg-dev, sizeof(struct dwc2_hcd_dma_desc)
+ * dwc2_max_desc_num(qh), qh-desc_list,
+ qh-desc_list_dma);
+

[PATCH v6 5/7] PCI bus interface for the DWC2 driver

This file contains the PCI bus interface glue for the DWC2 driver

Signed-off-by: Paul Zimmerman pa...@synopsys.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/dwc2/pci.c | 198 +
 1 file changed, 198 insertions(+)
 create mode 100644 drivers/usb/dwc2/pci.c

diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c
new file mode 100644
index 000..fd6278c
--- /dev/null
+++ b/drivers/usb/dwc2/pci.c
@@ -0,0 +1,198 @@
+/*
+ * pci.c - DesignWare HS OTG Controller PCI driver
+ *
+ * Copyright (C) 2004-2013 Synopsys, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, and the following disclaimer,
+ *without modification.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The names of the above-listed copyright holders may not be used
+ *to endorse or promote products derived from this software without
+ *specific prior written permission.
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation; either version 2 of the License, or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
+ * IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
+ * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+ * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+ * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+ * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * Provides the initialization and cleanup entry points for the DWC_otg PCI
+ * driver
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/pci.h
+#include linux/usb.h
+
+#include linux/usb/hcd.h
+#include linux/usb/ch11.h
+
+#include core.h
+#include hcd.h
+
+#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_PRODUCT_ID_HAPS_HSOTG  0xabc0
+
+static const char dwc2_driver_name[] = dwc_otg;
+
+static struct dwc2_core_params dwc2_module_params = {
+   .otg_cap= -1,
+   .otg_ver= -1,
+   .dma_enable = -1,
+   .dma_desc_enable= -1,
+   .speed  = -1,
+   .enable_dynamic_fifo= -1,
+   .en_multiple_tx_fifo= -1,
+   .host_rx_fifo_size  = 1024,
+   .host_nperio_tx_fifo_size   = 256,
+   .host_perio_tx_fifo_size= 1024,
+   .max_transfer_size  = 65535,
+   .max_packet_count   = 511,
+   .host_channels  = -1,
+   .phy_type   = -1,
+   .phy_utmi_width = 16,   /* 16 bits - NOT DETECTABLE */
+   .phy_ulpi_ddr   = -1,
+   .phy_ulpi_ext_vbus  = -1,
+   .i2c_enable = -1,
+   .ulpi_fs_ls = -1,
+   .host_support_fs_ls_low_power   = -1,
+   .host_ls_low_power_phy_clk  = -1,
+   .ts_dline   = -1,
+   .reload_ctl = -1,
+   .ahb_single = -1,
+};
+
+/**
+ * dwc2_driver_remove() - Called when the DWC_otg core is unregistered with the
+ * DWC_otg driver
+ *
+ * @dev: Bus device
+ *
+ * This routine is called, for example, when the rmmod command is executed. The
+ * device may or may not be electrically present. If it is present, the driver
+ * stops device processing. Any resources used on behalf of this device are
+ * freed.
+ */
+static void dwc2_driver_remove(struct pci_dev *dev)
+{
+   struct dwc2_hsotg *hsotg = pci_get_drvdata(dev);
+
+   dev_dbg(dev-dev, %s(%p)\n, __func__, dev);
+
+   dwc2_hcd_remove(dev-dev, hsotg);
+   pci_disable_device(dev);
+}
+
+/**
+ * dwc2_driver_probe() - Called when the DWC_otg core is bound to the DWC_otg
+ * driver
+ *
+ * @dev: Bus device
+ *
+ * This routine creates the driver components required to control the device
+ * (core, HCD, and

[PATCH v6 6/7] Hook the DWC2 driver into the build system

Add the DWC2 Kconfig and Makefile, and modify the USB Kconfig and
Makefile to include them

Signed-off-by: Paul Zimmerman pa...@synopsys.com
Acked-by: Felipe Balbi ba...@ti.com
---
 drivers/usb/Kconfig   |  2 ++
 drivers/usb/Makefile  |  2 ++
 drivers/usb/dwc2/Kconfig  | 41 +
 drivers/usb/dwc2/Makefile | 23 +++
 4 files changed, 68 insertions(+)
 create mode 100644 drivers/usb/dwc2/Kconfig
 create mode 100644 drivers/usb/dwc2/Makefile

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 640ae6c..570e65c 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -126,6 +126,8 @@ source drivers/usb/core/Kconfig
 
 source drivers/usb/dwc3/Kconfig
 
+source drivers/usb/dwc2/Kconfig
+
 source drivers/usb/mon/Kconfig
 
 source drivers/usb/wusbcore/Kconfig
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index f5ed3d7..efa98f7 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -10,6 +10,8 @@ obj-$(CONFIG_USB_OTG_UTILS)   += otg/
 
 obj-$(CONFIG_USB_DWC3) += dwc3/
 
+obj-$(CONFIG_USB_DWC2) += dwc2/
+
 obj-$(CONFIG_USB_MON)  += mon/
 
 obj-$(CONFIG_PCI)  += host/
diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig
new file mode 100644
index 000..610418a
--- /dev/null
+++ b/drivers/usb/dwc2/Kconfig
@@ -0,0 +1,41 @@
+config USB_DWC2
+   tristate DesignWare USB2 DRD Core Support
+   depends on USB
+   select USB_OTG_UTILS
+   help
+ Say Y or M here if your system has a Dual Role HighSpeed
+ USB controller based on the DesignWare HSOTG IP Core.
+
+ If you choose to build this driver as dynamically linked
+ modules, the core module will be called dwc2.ko, and the
+ PCI bus interface module (if you have a PCI bus system)
+ will be called dwc2_pci.ko.
+
+ NOTE: This driver at present only implements the Host mode
+ of the controller. The existing s3c-hsotg driver supports
+ Peripheral mode, but only for the Samsung S3C platforms.
+ There are plans to merge the s3c-hsotg driver with this
+ driver in the near future to create a dual-role driver.
+
+if USB_DWC2
+
+config USB_DWC2_DEBUG
+   bool Enable Debugging Messages
+   help
+ Say Y here to enable debugging messages in the DWC2 Driver.
+
+config USB_DWC2_VERBOSE
+   bool Enable Verbose Debugging Messages
+   depends on USB_DWC2_DEBUG
+   help
+ Say Y here to enable verbose debugging messages in the DWC2 Driver.
+ WARNING: Enabling this will quickly fill your message log.
+ If in doubt, say N.
+
+config USB_DWC2_TRACK_MISSED_SOFS
+   bool Enable Missed SOF Tracking
+   help
+ Say Y here to enable logging of missed SOF events to the dmesg log.
+ If in doubt, say N.
+
+endif
diff --git a/drivers/usb/dwc2/Makefile b/drivers/usb/dwc2/Makefile
new file mode 100644
index 000..6dccf46
--- /dev/null
+++ b/drivers/usb/dwc2/Makefile
@@ -0,0 +1,23 @@
+ccflags-$(CONFIG_USB_DWC2_DEBUG)   += -DDEBUG
+ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE_DEBUG
+
+obj-$(CONFIG_USB_DWC2) += dwc2.o
+
+dwc2-y += core.o core_intr.o
+
+# NOTE: This driver at present only implements the Host mode
+# of the controller. The existing s3c-hsotg driver supports
+# Peripheral mode, but only for the Samsung S3C platforms.
+# There are plans to merge the s3c-hsotg driver with this
+# driver in the near future to create a dual-role driver. Once
+# that is done, Host mode will become an optional feature that
+# is selected with a config option.
+
+dwc2-y += hcd.o hcd_intr.o
+dwc2-y += hcd_queue.o hcd_ddma.o
+
+ifneq ($(CONFIG_PCI),)
+   obj-$(CONFIG_USB_DWC2)  += dwc2_pci.o
+endif
+
+dwc2_pci-y += pci.o
-- 
1.8.2.rc0.16.g20a599e

--
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 v6 7/7] Add a MAINTAINERS entry for the DWC2 driver

Add myself as maintainer of the DWC2 driver

Signed-off-by: Paul Zimmerman pa...@synopsys.com
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..27874f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2470,6 +2470,12 @@ M:   Matthew Garrett mj...@srcf.ucam.org
 S: Maintained
 F: drivers/platform/x86/dell-wmi.c
 
+DESIGNWARE USB2 DRD IP DRIVER
+M: Paul Zimmerman pa...@synopsys.com
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/dwc2/
+
 DESIGNWARE USB3 DRD IP DRIVER
 M: Felipe Balbi ba...@ti.com
 L: linux-usb@vger.kernel.org
-- 
1.8.2.rc0.16.g20a599e

--
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/gadget: initialize gadget functions helper befor functions gadgets

2013-03-04 Thread Sebastian Andrzej Siewior

Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
into the kernel. The problem was that u_serial was used by g_cdc before
u_serial was initialized. In the module case eveything is initialized in
the correct order but if we compile it into the kernel we rely on
Makefile order which I did wrong and now I correct this.

Cc: Fengguang Wu fengguang...@intel.com
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
I kinda assumed that this was already fixed (i.e. a patch like this was sent)
but it seems not to be that case.

 drivers/usb/gadget/Makefile |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 97a13c3..1ded3d4 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -35,6 +35,12 @@ mv_udc-y := mv_udc_core.o
 obj-$(CONFIG_USB_FUSB300)  += fusb300_udc.o
 obj-$(CONFIG_USB_MV_U3D)   += mv_u3d_core.o
 
+# USB Functions
+obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
+obj-$(CONFIG_USB_F_ACM)+= f_acm.o
+f_ss_lb-y  := f_loopback.o f_sourcesink.o
+obj-$(CONFIG_USB_F_SS_LB)  += f_ss_lb.o
+
 #
 # USB gadget drivers
 #
@@ -74,9 +80,3 @@ obj-$(CONFIG_USB_G_WEBCAM)+= g_webcam.o
 obj-$(CONFIG_USB_G_NCM)+= g_ncm.o
 obj-$(CONFIG_USB_G_ACM_MS) += g_acm_ms.o
 obj-$(CONFIG_USB_GADGET_TARGET)+= tcm_usb_gadget.o
-
-# USB Functions
-obj-$(CONFIG_USB_F_ACM)+= f_acm.o
-f_ss_lb-y  := f_loopback.o f_sourcesink.o
-obj-$(CONFIG_USB_F_SS_LB)  += f_ss_lb.o
-obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
-- 
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

[RFC] USB: storage: in-kernel modeswitching is deprecated

Signed-off-by: Bjørn Mork bj...@mork.no
---
So, is something like this good enough?


Bjørn

 drivers/usb/storage/unusual_devs.h |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index d305a5a..1e03a45 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -53,6 +53,14 @@
  * as opposed to devices that do something strangely or wrongly.
  */
 
+/* In-kernel mode switching is deprecated.  Do not add new devices to
+ * this list for the sole purpose of switching to them to a different
+ * mode.  Existing userspace solutions are superior.
+ *
+ * New mode switching devices should instead be added to the database
+ * maintained at http://www.draisberghof.de/usb_modeswitch/
+ */
+
 #if !defined(CONFIG_USB_STORAGE_SDDR09)  \
!defined(CONFIG_USB_STORAGE_SDDR09_MODULE)
 #define NO_SDDR09
-- 
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: [RFC] USB: storage: in-kernel modeswitching is deprecated

2013-03-04 Thread Sergei Shtylyov


Hello.

On 03/05/2013 12:57 AM, Bjørn Mork wrote:


Signed-off-by: Bjørn Mork bj...@mork.no
---
So, is something like this good enough?


Bjørn

  drivers/usb/storage/unusual_devs.h |8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index d305a5a..1e03a45 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -53,6 +53,14 @@
   * as opposed to devices that do something strangely or wrongly.
   */
  
+/* In-kernel mode switching is deprecated.  Do not add new devices to

+ * this list for the sole purpose of switching to them to a different


   Too many to, I guess.

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: [PATCH] usb/gadget: initialize gadget functions helper befor functions gadgets

2013-03-04 Thread Michal Nazarewicz

On Mon, Mar 04 2013, Sebastian Andrzej Siewior wrote:
 Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
 into the kernel. The problem was that u_serial was used by g_cdc before
 u_serial was initialized. In the module case eveything is initialized in
 the correct order but if we compile it into the kernel we rely on
 Makefile order which I did wrong and now I correct this.

 Cc: Fengguang Wu fengguang...@intel.com

Should that be Reported-by?

 Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc

Acked-by: Michal Nazarewicz min...@mina86.com

 ---
 I kinda assumed that this was already fixed (i.e. a patch like this was sent)
 but it seems not to be that case.

  drivers/usb/gadget/Makefile |   12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
 index 97a13c3..1ded3d4 100644
 --- a/drivers/usb/gadget/Makefile
 +++ b/drivers/usb/gadget/Makefile
 @@ -35,6 +35,12 @@ mv_udc-y   := mv_udc_core.o
  obj-$(CONFIG_USB_FUSB300)+= fusb300_udc.o
  obj-$(CONFIG_USB_MV_U3D) += mv_u3d_core.o
  
 +# USB Functions

Should there be a comment explaining why USB functions must be placed
before gadgets?

 +obj-$(CONFIG_USB_U_SERIAL)   += u_serial.o
 +obj-$(CONFIG_USB_F_ACM)  += f_acm.o
 +f_ss_lb-y:= f_loopback.o f_sourcesink.o
 +obj-$(CONFIG_USB_F_SS_LB)+= f_ss_lb.o
 +
  #
  # USB gadget drivers
  #
 @@ -74,9 +80,3 @@ obj-$(CONFIG_USB_G_WEBCAM)  += g_webcam.o
  obj-$(CONFIG_USB_G_NCM)  += g_ncm.o
  obj-$(CONFIG_USB_G_ACM_MS)   += g_acm_ms.o
  obj-$(CONFIG_USB_GADGET_TARGET)  += tcm_usb_gadget.o
 -
 -# USB Functions
 -obj-$(CONFIG_USB_F_ACM)  += f_acm.o
 -f_ss_lb-y:= f_loopback.o f_sourcesink.o
 -obj-$(CONFIG_USB_F_SS_LB)+= f_ss_lb.o
 -obj-$(CONFIG_USB_U_SERIAL)   += u_serial.o



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

pgpRVYNdCfQTd.pgp
Description: PGP signature

Re: [RFC] USB: storage: in-kernel modeswitching is deprecated

2013-03-04 Thread Ben Hutchings

On Mon, Mar 04, 2013 at 10:57:22PM +0100, Bjørn Mork wrote:
 Signed-off-by: Bjørn Mork bj...@mork.no
 ---
 So, is something like this good enough?
 
 
 Bjørn
[...]
 
I think this comment is good, but then it's not my driver.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus
--
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: fix trivial usb_device kernel-doc errors

2013-03-04 Thread Nishanth Menon

Fix trivial kernel-doc warnings:
Warning(include/linux/usb.h:574): No description found for parameter 
'usb3_lpm_enabled'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member 
'usb_classdev' description in 'usb_device'
Warning(include/linux/usb.h:574): Excess struct/union/enum/typedef member 
'usbfs_dentry' description in 'usb_device'

Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Kosina triv...@kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Signed-off-by: Nishanth Menon n...@ti.com
---
 include/linux/usb.h |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/usb.h b/include/linux/usb.h
index 4d22d0f..52464fb 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -469,14 +469,12 @@ struct usb3_lpm_parameters {
  * @lpm_capable: device supports LPM
  * @usb2_hw_lpm_capable: device can perform USB2 hardware LPM
  * @usb2_hw_lpm_enabled: USB2 hardware LPM enabled
+ * @usb3_lpm_enabled: USB3 hardware LPM enabled
  * @string_langid: language ID for strings
  * @product: iProduct string, if present (static)
  * @manufacturer: iManufacturer string, if present (static)
  * @serial: iSerialNumber string, if present (static)
  * @filelist: usbfs files that are open to this device
- * @usb_classdev: USB class device that was created for usbfs device
- * access from userspace
- * @usbfs_dentry: usbfs dentry entry for the device
  * @maxchild: number of ports if hub
  * @quirks: quirks of the whole device
  * @urbnum: number of URBs submitted for the whole device
-- 
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

[PATCH] usb: gadget: composite: fix kernel-doc warnings

2013-03-04 Thread Nishanth Menon

A few trivial fixes for composite driver.
Fixes:
Warning(include/linux/usb/composite.h:165): No description found for parameter 
'fs_descriptors'
Warning(include/linux/usb/composite.h:165): Excess struct/union/enum/typedef 
member 'descriptors' description in 'usb_function'
Warning(include/linux/usb/composite.h:321): No description found for parameter 
'gadget_driver'
Warning(drivers/usb/gadget/composite.c:1777): Excess function parameter 'bind' 
description in 'usb_composite_probe'

Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Kosina triv...@kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Signed-off-by: Nishanth Menon n...@ti.com
---
 drivers/usb/gadget/composite.c |5 +
 include/linux/usb/composite.h  |3 ++-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 7c821de..c0d62b2 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1757,10 +1757,7 @@ static const struct usb_gadget_driver 
composite_driver_template = {
 /**
  * usb_composite_probe() - register a composite driver
  * @driver: the driver to register
- * @bind: the callback used to allocate resources that are shared across the
- * whole device, such as string IDs, and add its configurations using
- * @usb_add_config().  This may fail by returning a negative errno
- * value; it should return zero on successful initialization.
+ *
  * Context: single threaded during gadget setup
  *
  * This function is used to register drivers using the composite driver
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 3c671c1..8860594 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -60,7 +60,7 @@ struct usb_configuration;
  * @name: For diagnostics, identifies the function.
  * @strings: tables of strings, keyed by identifiers assigned during bind()
  * and by language IDs provided in control requests
- * @descriptors: Table of full (or low) speed descriptors, using interface and
+ * @fs_descriptors: Table of full (or low) speed descriptors, using interface 
and
  * string identifiers assigned during @bind().  If this pointer is null,
  * the function will not be available at full speed (or at low speed).
  * @hs_descriptors: Table of high speed descriptors, using interface and
@@ -290,6 +290,7 @@ enum {
  * after function notifications
  * @resume: Notifies configuration when the host restarts USB traffic,
  * before function notifications
+ * @gadget_driver: Gadget driver controlling this driver
  *
  * Devices default to reporting self powered operation.  Devices which rely
  * on bus powered operation should report this in their @bind method.
-- 
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: [RFC] USB: storage: in-kernel modeswitching is deprecated

2013-03-04 Thread Matthew Dharm

I'm happy with it, modulo Sergi's grammer comment.

ACKed-by: Matthew Dharm mdharm-...@one-eyed-alien.net

Matt

On Mon, Mar 4, 2013 at 1:57 PM, Bjørn Mork bj...@mork.no wrote:
 Signed-off-by: Bjørn Mork bj...@mork.no
 ---
 So, is something like this good enough?


 Bjørn

  drivers/usb/storage/unusual_devs.h |8 
  1 file changed, 8 insertions(+)

 diff --git a/drivers/usb/storage/unusual_devs.h 
 b/drivers/usb/storage/unusual_devs.h
 index d305a5a..1e03a45 100644
 --- a/drivers/usb/storage/unusual_devs.h
 +++ b/drivers/usb/storage/unusual_devs.h
 @@ -53,6 +53,14 @@
   * as opposed to devices that do something strangely or wrongly.
   */

 +/* In-kernel mode switching is deprecated.  Do not add new devices to
 + * this list for the sole purpose of switching to them to a different
 + * mode.  Existing userspace solutions are superior.
 + *
 + * New mode switching devices should instead be added to the database
 + * maintained at http://www.draisberghof.de/usb_modeswitch/
 + */
 +
  #if !defined(CONFIG_USB_STORAGE_SDDR09)  \
 !defined(CONFIG_USB_STORAGE_SDDR09_MODULE)
  #define NO_SDDR09
 --
 1.7.10.4




--
Matthew Dharm
Maintainer, USB Mass Storage driver for Linux
--
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: storage: fix Huawei mode switching regression

2013-03-04 Thread Josua Dietze


Am 04.03.2013 20:22, schrieb Bjørn Mork:

Matthew Dharm mdharm-...@one-eyed-alien.net writes:

The question is not one of reminding me of what I said earlier
it's one of pointing people in the right direction.  Frankly, some of
the fault for this patch lies with Greg and myself for letting it
through.  I had just assumed that the Huawei guys had already been in
touch with usb-modeswitch for some reason, and that this was just an
optimization of existing logic (not an expansion).


I was contacted at one point by a Huawei engineer who convinced me to change 
the default mode-switching 'message' for all Huawei devices.
The reason was the introduction of an 'advanced' Linux driver by Huawei which 
requires a specific target mode. This was in October 2010.
No contact attempt since then.


Who is maintaining usb-modeswitch these days, anyway?  The comment in
the file should point people directly there


I never ceased work on it and intend to do so for years to come. I would 
certainly welcome any pointer to the usb_modeswitch main site in the code or 
the documentation. Although modem developers or engineers should not have a 
problem finding the site and providing new device information.


And, as of now, I would really like to see as many of these devices
migrated (albeit slowly) to using usb-modeswitch wherever possible.  I
know there are a few devices for which that might not be possible, but
I am DONE dealing with this same issue over and over and over again.
It will certainly be work to migrate support; maybe we should wrap all
the relevant unusual_devs.h entires with
CONFIG_UPDATED_MODESWITCH_INSTALLED_SO_MAKE_THESE_GO_AWAY during a
transition period?


I think it's safe to say that usb_modeswitch is included in all distributions 
now. Usually, no user interaction is necessary.


I guess the real problem will be verifying that all of the entries *can*
go away. This type of hardware tends to get old very fast, but there is
always someone having a really ancient device.


I will check this and add any missing USB IDs to usb_modeswitch, but I can't shake the 
feeling that not *all* Huawei entries in unusual_devs.h did actually 
materialize as devices ...

Anyway, as Bjørn said, putting that initialization into the storage driver 
takes away quite some possibilities to handle these modems in a flexible way.


Josua Dietze

--
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 v6 0/7] DWC2 DesignWare HS OTG driver

2013-03-04 Thread Greg KH

On Mon, Mar 04, 2013 at 12:21:43PM -0800, Paul Zimmerman wrote:
 Hi Greg,
 
 Here is the latest version of the DWC2 patch set. This version includes
 changes suggested by Felipe in his last review, plus a couple of changes
 requested by Alan Stern.
 
 Please consider applying these to usb-next. Felipe thought these should
 go in through your tree, since they don't contain any gadget-related
 code (yet). Thanks.

I need an ack from Felipe on this before I can take it (I trust him more
than I trust myself here...)

Felipe?

--
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: host: tegra: Reset Tegra USB controller before init

2013-03-04 Thread gre...@linuxfoundation.org

On Mon, Mar 04, 2013 at 09:55:44AM -0700, Stephen Warren wrote:
 On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
  Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
  On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
  To clear any configurations made by U-Boot on Tegra USB controller,
  reset it before init in probe.
 
  diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
 
  @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device
  *pdev)
if (err)
goto fail_clk;
 
  + tegra_periph_reset_assert(tegra-clk);
  + udelay(1);
  + tegra_periph_reset_deassert(tegra-clk);
 
  I think this patch might cause unintended consequences.
 
  When the Tegra PHY code is converted to a driver (i.e. has its own
  probe), the initial order of execution of the PHY and EHCI driver probes
  will not be guaranteed.
 
  In particular, since the EHCI probe will attempt to find the PHY
  device, and defer the EHCI probe until it can do so, this guarantees
  that the PHY's probe() will have completed before EHCI's probe()
  completes (although EHCI's probe may start running first some number of
  times, and be retried with -EPROBE_DEFERRED for a variety of reasons).
 
  Now, if the PHY driver's probe() actually touches HW and sets up some
  registers, isn't this reset call going to trash any of that register
  setup? Or, will PHY probe() not touch registers, but only do so during
  the standard PHY open/init op/API calls?
   
  Yes, PHY driver probe does not touch any registers. It just sets up the PHY 
  API hooks.
  These APIs will be called from ehci-tegra.c as part of ehci tegra probe 
  function, after
  getting  PHY handle, which in turn happens after issuing above reset.
  
  Thanks to Stephen  Alan, for the review comments.
 
 OK, in that case I have no objection to this patch.
 
 I'd like to hold off on applying this though; I suspect I'll want to
 take the Tegra USB patches through the Tegra tree rather than the USB
 tree again for the 3.10 kernel cycle. I think I may have screwed the
 pooch on the DT binding I set up for the USB controller clocks, and
 fixing this may require some Tegra DT changes, which would be easiest
 taken through the Tegra tree, and so to reduce conflicts in the USB
 code, taking the rest through there migth just be easiest.
 
 Alan, Greg, if you're OK with this patch now, or for any revised
 version, an Ack so I can take it through the Tegra tree would be great,
 thanks.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
--
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: [GIT PULL] usb: fixes for v3.9-rc2

2013-03-04 Thread Greg KH

On Mon, Mar 04, 2013 at 02:24:20PM +0200, Felipe Balbi wrote:
 Hi Greg,
 
 Here's my first set of fixes for the v3.9-rc cycle. Nothing scary, all fixes
 have been pending for a while now. I ran a few randconfig cycles with my
 own seed, all looks good.
 
 Let me know if you want any changes.
 
 The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
 
   Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
 tags/fixes-for-v3.9-rc2

Thanks, pulled and pushed out.

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] drivers/usb/gadget: using strlcpy instead of strncpy

2013-03-04 Thread Chen Gang

于 2013年03月02日 03:47, Laurent Pinchart 写道:
 I've taken the patch in my tree.
 
 I've just sent a consolidated series of most pending UVC gadget patches to 
 the 
 list, and I will send you a pull request as soon as I receive a Tested-by.

  thanks

-- 
Chen Gang

Asianux Corporation
--
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

2013-03-04 Thread Chen Gang

于 2013年03月04日 22:35, Felipe Balbi 写道:
 this is the wrong fix, I believe. Looks like when I wrote the commits
 you mention, I deleted more code then I should. Looks like the real fix
 would be to add back:
 
   /* report disconnect; the driver is already quiesced */
   if (driver) {
   spin_unlock(dev-lock);
   driver-disconnect(dev-gadget);
   spin_lock(dev-lock);
   }
 

  ok, thanks.


 since stop_activity() also gets called from RESET interrupt, and in that
 case we need to call driver-disconnect(). Can you make a simple test
 that would take current code and issue a device reset to see if that
 would break, then apply my suggestion above and run the same test again?
 

  ok, thanks, that is what I should do.

  but excuse me for my time limitation:
in these days, my father had a serious heart disease in hospital.
  within this week end, most of my time has to be in hospital.
(God bless, and thank Jesus Christ, my father is safe now).
within my company (Asianux), also has something to do.

  so I try to finish it in next week end (Mar-15-2013).

  if we can not bear the time point, please reply (or prefer another
member to finish it)

  thanks.

  :-)

 If you want, I have a simple libusb-1.0-based little app which can issue
 resets to any device you ask. Currently it will reset a device 10K
 times but you can remove the for loop if you want:

  thank you for your information, they are valuable to me.

-- 
Chen Gang

Asianux Corporation
--
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: [V8 PATCH 01/16] usb: phy: mv_usb2: add PHY driver for marvell usb2 controller

2013-03-04 Thread Chao Xie

On Mon, Mar 4, 2013 at 10:21 PM, Felipe Balbi ba...@ti.com wrote:
 On Wed, Feb 20, 2013 at 11:07:11PM -0500, Chao Xie wrote:
 The PHY is seperated from usb controller.
 The usb controller used in marvell pxa168/pxa910/mmp2 are same,
 but PHY initialization may be different.
 the usb controller can support udc/otg/ehci, and for each of
 the mode, it need PHY to initialized before use the controller.
 Direclty writing the phy driver will make the usb controller
 driver to be simple and portable.
 The PHY driver will be used by marvell udc/otg/ehci.

 Signed-off-by: Chao Xie chao@marvell.com
 ---
  drivers/usb/phy/Kconfig  |7 +
  drivers/usb/phy/Makefile |1 +
  drivers/usb/phy/mv_usb2_phy.c|  402 
 ++
  include/linux/platform_data/mv_usb.h |9 +-
  include/linux/usb/mv_usb2.h  |   32 +++
  5 files changed, 448 insertions(+), 3 deletions(-)
  create mode 100644 drivers/usb/phy/mv_usb2_phy.c
  create mode 100644 include/linux/usb/mv_usb2.h

 diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
 index 65217a5..5479760 100644
 --- a/drivers/usb/phy/Kconfig
 +++ b/drivers/usb/phy/Kconfig
 @@ -73,3 +73,10 @@ config SAMSUNG_USBPHY
   help
 Enable this to support Samsung USB phy controller for samsung
 SoCs.
 +
 +config MV_USB2_PHY
 + tristate Marvell USB 2.0 PHY Driver
 + depends on USB || USB_GADGET

 NAK, PHYs don't depend on the gadget framework.

Sure, i will remove it.


 + help
 +   Enable this to support Marvell USB 2.0 phy driver for Marvell
 +   SoC.
 diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
 index b13faa1..3835316 100644
 --- a/drivers/usb/phy/Makefile
 +++ b/drivers/usb/phy/Makefile
 @@ -12,3 +12,4 @@ obj-$(CONFIG_MV_U3D_PHY)+= mv_u3d_phy.o
  obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
  obj-$(CONFIG_USB_RCAR_PHY)   += rcar-phy.o
  obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
 +obj-$(CONFIG_MV_USB2_PHY)+= mv_usb2_phy.o
 diff --git a/drivers/usb/phy/mv_usb2_phy.c b/drivers/usb/phy/mv_usb2_phy.c
 new file mode 100644
 index 000..a81e5e4
 --- /dev/null
 +++ b/drivers/usb/phy/mv_usb2_phy.c
 @@ -0,0 +1,402 @@
 +/*
 + * Copyright (C) 2013 Marvell Inc.
 + *
 + * Author:
 + *   Chao Xie xiechao.m...@gmail.com
 + *
 + * This software is licensed under the terms of the GNU General Public
 + * License version 2, as published by the Free Software Foundation, and

 +#define UTMI_CTRL0x4
 +#define UTMI_PLL 0x8
 +#define UTMI_TX  0xc
 +#define UTMI_RX  0x10
 +#define UTMI_IVREF   0x14
 +#define UTMI_T0  0x18
 +#define UTMI_T1  0x1c
 +#define UTMI_T2  0x20
 +#define UTMI_T3  0x24
 +#define UTMI_T4  0x28
 +#define UTMI_T5  0x2c
 +#define UTMI_RESERVE 0x30
 +#define UTMI_USB_INT 0x34
 +#define UTMI_DBG_CTL 0x38
 +#define UTMI_OTG_ADDON   0x3c

 prepend these with MV_USB_

Fine.


 +enum mv_usb2_phy_type {
 + PXA168_USB,
 + PXA910_USB,
 + MMP2_USB,
 +};


 ewww... you really don't need (and *shouldn't* use) u2o_set() or
 u2o_clear(). They clearly prevent compiler from optimizing variable
 usage and could cause pressure on your interconnect. By writing and
 reading multiple times for no reason.


The APIs defined here is for device operation. The device register
read/write is not same as memory.
When a silicon comes, it may not be stable, and will have done some
workaround epecially for the
device register read/write. to define the APIs for the register
read/write will help to implement the workaround
without changing phy init code every time.
Now the only constrain is should read back the registers if you have
writen to it.
It will low down the performance, but it does not matter. Because phy
init will only done once when you initialize it.
I will think about reove the u2o_xxx APIs.

 +static int _mv_usb2_phy_init(struct mv_usb2_phy *mv_phy)
 +{
 + struct platform_device *pdev = mv_phy-pdev;
 + unsigned int loops = 0;
 + void __iomem *base = mv_phy-base;
 +
 + dev_dbg(pdev-dev, phy init\n);

 remove this debugging message.

 + /* Initialize the USB PHY power */
 + if (mv_phy-type == PXA910_USB) {

 you _do_ have a REVISION register. Are you 100% certain that revision is
 the same on all your devices ? It seems to me that you should be doing
 proper revision detection instead of adding the hacky enumeration of
 yours.

We do not have revison registers and will do not want ot define
#ifdef CPU_PXA910 or CPU_PXA_XXX
or
use is_cpu_pxa910 or cpu_pxa_xxx
because it is not acceptable. for example, if we have new SOC and it
use the same PHY as pxa910
i have to change the USB driver code to support it. for example
#ifdef CPU_PXA910 || CPU_XXX

So i have to depends

Re: [V8 PATCH 02/16] usb: gadget: mv_udc: use PHY driver for udc

2013-03-04 Thread Chao Xie

On Mon, Mar 4, 2013 at 10:24 PM, Felipe Balbi ba...@ti.com wrote:
 On Wed, Feb 20, 2013 at 11:07:12PM -0500, Chao Xie wrote:
 Originaly, udc driver will call the callbacks in platform data
 for PHY initialization and shut down.
 With PHY driver, it will call the APIs provided by PHY driver
 for PHY initialization and shut down. It removes the callbacks
 in platform data, and at same time it removes one block in the
 way of enabling device tree for udc driver.

 Signed-off-by: Chao Xie chao@marvell.com
 ---
  drivers/usb/gadget/mv_udc.h  |2 +-
  drivers/usb/gadget/mv_udc_core.c |   45 
 ++---
  2 files changed, 18 insertions(+), 29 deletions(-)

 diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
 index 9073436..f339df4 100644
 --- a/drivers/usb/gadget/mv_udc.h
 +++ b/drivers/usb/gadget/mv_udc.h
 @@ -180,7 +180,6 @@ struct mv_udc {

   struct mv_cap_regs __iomem  *cap_regs;
   struct mv_op_regs __iomem   *op_regs;
 - void __iomem*phy_regs;
   unsigned intmax_eps;
   struct mv_dqh   *ep_dqh;
   size_t  ep_dqh_size;
 @@ -217,6 +216,7 @@ struct mv_udc {
   struct work_struct  vbus_work;
   struct workqueue_struct *qwork;

 + struct usb_phy  *phy;
   struct usb_phy  *transceiver;

   struct mv_usb_platform_data *pdata;
 diff --git a/drivers/usb/gadget/mv_udc_core.c 
 b/drivers/usb/gadget/mv_udc_core.c
 index c8cf959..4876d2f 100644
 --- a/drivers/usb/gadget/mv_udc_core.c
 +++ b/drivers/usb/gadget/mv_udc_core.c
 @@ -35,6 +35,7 @@
  #include linux/platform_device.h
  #include linux/clk.h
  #include linux/platform_data/mv_usb.h
 +#include linux/usb/mv_usb2.h
  #include asm/unaligned.h

  #include mv_udc.h
 @@ -1121,15 +1122,14 @@ static int mv_udc_enable_internal(struct mv_udc *udc)

   dev_dbg(udc-dev-dev, enable udc\n);
   udc_clock_enable(udc);
 - if (udc-pdata-phy_init) {
 - retval = udc-pdata-phy_init(udc-phy_regs);
 - if (retval) {
 - dev_err(udc-dev-dev,
 - init phy error %d\n, retval);
 - udc_clock_disable(udc);
 - return retval;
 - }

 dude, you really don't test your patches, do you ? Your previous patch
 removed -phy_init(), -phy_deinit() and -private_init() from your
 platform_data.

 Are you seriously telling me you didn't compile test your patches ?

 Rewrite your series again and make sure that each and every patch
 compiles and works on its own. You shouldn't cause any regressions or
 build breaks or build warnings while converting this driver.

 I won't review the rest of this series and I'm purging it from my TODO
 list.


Thanks for your review.

The patches are seperated into two parts. for  each part it includes
some patches.
I have compiled and tested each part for our configurartion and x86
configuration, but
not for every patch. i will do it.

 cheers

 --
 balbi
--
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: storage: fix Huawei mode switching regression

2013-03-04 Thread Fangxiaozhi (Franko)



 -Original Message-
 From: Bjørn Mork [mailto:bj...@mork.no]
 Sent: Monday, March 04, 2013 9:19 PM
 To: linux-usb@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org; Fangxiaozhi (Franko); Xueguiying (Zihan);
 Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C);
 ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc;
 Bjørn Mork; stable
 Subject: [PATCH] USB: storage: fix Huawei mode switching regression
 
 This reverts commit 200e0d99 (USB: storage: optimize to match the Huawei
 USB storage devices and support new switch command and the followup
 bugfix commit cd060956 (USB: storage: properly handle the endian issues of
 idProduct).
 
 The commit effectively added a large number of Huawei devices to the
 deprecated usb-storage mode switching logic.  Many of these devices have
 been in use and supported by the userspace usb_modeswitch utility for years.
 Forcing the switching inside the kernel causes a number of regressions as a
 result of ignoring existing onfigurations, and also completely takes away the
 ability to configure mode switching per device/system/user.
-- commit 200e0d99 and commit cd060956, only put the switch command into 
kernel, instead of userspace usb_modeswitch utility. 
-- Because in the embedded linux system, Android, or Chrome OS, etc. They 
don't integrate userspace usb_modeswitch utility for switching.
- In commit 200e0d99, we send the Linux switching command to Huawei 
devices, so on PC Linux, you can get the largest capacity of Huawei device, 
including the CDROM feature. So I think this solution can meet the user's 
requirement in Linux.

 
 Known regressions caused by this:
  - Some of the devices support multiple modes, using different
   switching commands.  There are existing configurations taking
   advantage of this.
---But in this multiple modes, there is only one is for Linux. We don't 
advice the user to use the other mode not for Linux. It may cause some 
unexpected problem.
 
  - There is a real use case for disabling mode switching and
   instead mounting the exposed storage device. This becomes
   impossible with switching logic inside the usb-storage driver.
In commit 200e0d99, the switching command will ask Huawei device to offer 
the CDROM(and /or SD) port together. After switching, users also can get the 
mounting storage device.
 
  - At least on device fail as a result of the usb-storage switching
   command, becoming completely unswitchable. This is possibly a
   firmware bug, but still a regression because the device work as
   expected using usb_modeswitch defaults.
- If the kernel solution encounters this issue, then it also will occur 
with usb_modeswitch.

 
 In-kernel mode switching was deprecated years ago with the development of
 the more user friendly userspace alternatives. The existing list of devices in
 usb-storage was only kept to prevent breaking already working systems.  The
 long term plan is to remove the list, not to add to it. Ref:
 http://permalink.gmane.org/gmane.linux.usb.general/28543
 
 Cc: fangxiao...@huawei.com
 Cc: stable sta...@vger.kernel.org
 Signed-off-by: Bjørn Mork bj...@mork.no
 ---
 I just realized that this already had gone into maintained stable series', 
 making
 the fix so much more urgent.  This needs to be reverted before it starts
 hitting innocent distro users.  So I am sending the patch now instead of
 waiting for Huawei to respond.
-- In our opinions, it is better to switch Huawei device in kernel. 
-- usb_modeswitch is a tool for Linux. 
-- We can not guarantee it will be integrated in all the system which 
integrates linux kernel. But linux kernel itself can.

 
 
 Bjørn
 

Best Regards,
Franko Fang

  drivers/usb/storage/initializers.c |   76 +
  drivers/usb/storage/initializers.h |4 +-
  drivers/usb/storage/unusual_devs.h |  329
 +++-
  3 files changed, 331 insertions(+), 78 deletions(-)
 
 diff --git a/drivers/usb/storage/initializers.c 
 b/drivers/usb/storage/initializers.c
 index 7ab9046..105d900 100644
 --- a/drivers/usb/storage/initializers.c
 +++ b/drivers/usb/storage/initializers.c
 @@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_data *us)
   return 0;
  }
 
 -/* This places the HUAWEI usb dongles in multi-port mode */ -static int
 usb_stor_huawei_feature_init(struct us_data *us)
 +/* This places the HUAWEI E220 devices in multi-port mode */ int
 +usb_stor_huawei_e220_init(struct us_data *us)
  {
   int result;
 
 @@ -104,75 +104,3 @@ static int usb_stor_huawei_feature_init(struct
 us_data *us)
   US_DEBUGP(Huawei mode set result is %d\n, result);
   return 0;
  }
 -
 -/*
 - * It will send a scsi switch command called rewind' to huawei dongle.
 - * When the dongle receives this command at the first time,
 - * it will reboot immediately. After rebooted, it will ignore this command.
 - * So it is  unnecessary to read its response.
 - */
 -static int

RE: v3.8 regression: Huawei mode switching fails (was Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command)

2013-03-04 Thread Fangxiaozhi (Franko)

Dear Mork:

Thank you very much for your test.

-Original Message-
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Monday, March 04, 2013 7:41 PM
To: Fangxiaozhi (Franko)
Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying
(Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger,
Credit);
Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
sebast...@breakpoint.cc
Subject: v3.8 regression: Huawei mode switching fails (was Re: [PATCH
2/2]linux-usb:optimize to match the Huawei USB storage devices and support
new switch command)

Hello Franko,

This patch causes a number of regressions for both the Huawei devices I have
available for testing. One of them is completely unusable in v3.8 (unable to
switch to modem mode) unless the usb-storage driver is disabled.
--Which device, can you tell me more information?
--Which model? And what's its firmware version?

I realize that some devices are historically handled by the usb-storage
driver,
but userspace modeswitching is the rule for new devices AFAIK.
I see absolutely no valid argument for adding new devices. And there is
absolutely no excuse for adding devices which have been handled by
userspace switching for years! The patch does not just optimize
matching. It adds a large number of devices which were previously handled
just fine by usb_modeswitch. This is guaranteed to confuse users with existing
configurations, and users looking up any of the existing documentation
pointing to usb_modeswitch.
--Yes. But there is some problems for this:
1. As far as I know, usb_modeswitch is now only integrated in the PC
Linux. It isn't integrated to other system with linux kernel, such as Android,
Chrome OS, etc. On these system, how can we switch the device?

2. usb_modeswitch often sends the Windows switching command to switch
Huawei device, but not sends Linux switching command. This maybe causes some
unexpected problem.

There is no need to repeat the discussion of kernel vs userspace switching. I
will only note that userspace switching:
- has been selected as the rule for new devices,
- allow the user to temporarily disable switching e.g. for mounting and
inspecting the usb-storage exported data,
- allow the user/system to apply device specific switching quirks

The v3.7-v3.8 regressions I observe are:

1) Temporarily disabling mode switching and mounting the CD image is now
impossible. Mode switching can only be disabled by blacklisting
usb-storage, which of course prevents usb-storage from working

Prior to v3.8, modeswitching could easily be disabled by userspace
configuration. The change breaks existing configurations.

2) Switching to non-default modes is now impossible. The E392 (initially
appearing as 12d1:1505) Windows drivers will use a different command than
the one used by Linux, causing the device to select a different configuration
in Linux and Windows. This forces Linux and Windows to see the device
differently.

Prior to v3.8, different modeswitching commands could be configured per
device. The change breaks existing configurations.

3) Switching fails for some devices. The E367 (initially appearing as
12d1:1446) does not switch when it receives the command sent by
usb-storage. But the command disable further switching, preventing
userspace switching from working as well.

Prior to v3.8, the device would switch fine using a default usb_modeswitch
configuration. The change breaks existing configurations.

I do note that there is a slight difference between the known working
usb_modeswitch command:

55534243123456780011062001

and the command sent by usb-storage:

char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

I assume the cause of the failure is either this difference or some timing
issue.

Anyway, I believe this patch must be reverted. It disables currently used,
well
documented, and extremely useful, userspace funtionaliy for all devices
implicitly added by the conversion from device matching to vendor matching.

Bjørn

Best Regards,
Franko Fang
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: [PATCH] drivers/usb/gadget: using strlcpy instead of strncpy

2013-03-04 Thread Chen Gang

于 2013年03月04日 01:35, Laurent Pinchart 写道:
 On Sunday 03 March 2013 01:23:46 Felipe Balbi wrote:
  On Fri, Mar 01, 2013 at 08:47:34PM +0100, Laurent Pinchart wrote:
   On Wednesday 27 February 2013 10:26:23 Felipe Balbi wrote:
On Sat, Feb 02, 2013 at 03:48:54PM +0800, Chen Gang wrote:
   for NUL terminated string, better notice '\0' in the end.
 
 Signed-off-by: Chen Gang gang.c...@asianux.com

Laurent, are you taking this patch or should I ?
   
   I've taken the patch in my tree.
   
   I've just sent a consolidated series of most pending UVC gadget patches 
   to
   the list, and I will send you a pull request as soon as I receive a
   Tested-by.
 
  I'll take them as patches.
 No problem. Bhupesh wrote that he would test the patches this week. Hopefully 
 there will be no further issue.


  thank you for your work.

  :-)


-- 
Chen Gang

Asianux Corporation
--
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

2013-03-04 Thread Bo Shen


Hi Alan,

On 3/4/2013 23:16, Alan Stern wrote:

On Mon, 4 Mar 2013, Bo Shen wrote:


Hi Alan,

On 02/26/2013 04:54 AM, Alan Stern wrote:

Sarah (and anyone else who's interested):

A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8 EHCI
controllers.  You pointed out that these are rather old components, not
being used in current systems, which is quite true.


I test this on Atmel at91sam9x5ek board with Linux-3.8. And get the
similar information. So please indicate me more detail information about
the bug. (Sorry for not catch the hardware bug e-mail)


The problem is explained in more detail here:

http://marc.info/?l=linux-usbm=135492071812265w=2

Note that the test program itself requires a small fix, which was
posted here:

http://marc.info/?l=linux-usbm=136226443502631w=2



Thanks.


If you don't mind, I'd like to see the kernel log from your test run.


The dmesg log information as following:

root@at91sam9x5ek:~# ./ehci-test /dev/bus/usb/001/003
atmel-ehci 70.ehci: EHCI hardware bug detected: 82008d80 8d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 02008d80 80008d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 02008d80 80008d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 82008d80 8d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 82008d80 8d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 02008d80 80008d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 82008d80 8d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 02008d80 80008d00
atmel-ehci 70.ehci: EHCI hardware bug detected: 82008d80 9d00

Best Regards,
Bo Shen
--
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 0/7] USB: don't recover device if suspend fails in system sleep

Hi,

This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case, otherwise the URB traffic scheduled
in recovery of failure path may cross system sleep, and may
cause problems.

Also fixes the USB serial, HID and several usbnet drivers
which may recover device in suspend failure path of system sleep.

Thanks,
--
Ming Lei

--
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/7] USB: adds comment on suspend callback

This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case.

Signed-off-by: Ming Lei ming@canonical.com
---
 include/linux/usb.h |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/usb.h b/include/linux/usb.h
index 4d22d0f..ea9d7cb 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -978,7 +978,10 @@ struct usbdrv_wrap {
  * the usbfs filesystem.  This lets devices provide ways to
  * expose information to user space regardless of where they
  * do (or don't) show up otherwise in the filesystem.
- * @suspend: Called when the device is going to be suspended by the system.
+ * @suspend: Called when the device is going to be suspended by the
+ * system either from system sleep or runtime suspend context, and
+ * its failed return value will be ignored in system sleep context,
+ * so do NOT try to recover device for this case.
  * @resume: Called when the device is being resumed by the system.
  * @reset_resume: Called when the suspended device has been reset instead
  * of being resumed.
-- 
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

[PATCH 2/7] USB: serial: handle suspend failure path correctly

This patch kills traffic even though type-suspend returns
failure inside usb_serial_suspend from system sleep context
because USB core ignores the failiure and lets system sleep
go ahread, so the serial URB traffic need to be killed
in this case.

Cc: Johan Hovold jhov...@gmail.com
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/usb/serial/usb-serial.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index a19ed74..04ad3d5 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -1144,7 +1144,8 @@ int usb_serial_suspend(struct usb_interface *intf, 
pm_message_t message)
r = serial-type-suspend(serial, message);
if (r  0) {
serial-suspending = 0;
-   goto err_out;
+   if (PMSG_IS_AUTO(msg))
+   goto err_out;
}
}
 
-- 
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

[PATCH 3/7] USBHID: don't recover device if suspend fails in system sleep

If suspend callback fails in system sleep context, usb core will
ignore the failure and let the system sleep go ahead further, so this
patch doesn't recover device under this situation.

Cc: Jiri Kosina jkos...@suse.cz
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/hid/usbhid/hid-core.c |   14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 8e0c4bf94..a15ec29 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1493,7 +1493,7 @@ static int hid_suspend(struct usb_interface *intf, 
pm_message_t message)
 {
struct hid_device *hid = usb_get_intfdata(intf);
struct usbhid_device *usbhid = hid-driver_data;
-   int status;
+   int status = 0;
bool driver_suspended = false;
 
if (PMSG_IS_AUTO(message)) {
@@ -1520,19 +1520,15 @@ static int hid_suspend(struct usb_interface *intf, 
pm_message_t message)
}
 
} else {
-   if (hid-driver  hid-driver-suspend) {
+   /* Ignore failure return value in system sleep */
+   if (hid-driver  hid-driver-suspend)
status = hid-driver-suspend(hid, message);
-   if (status  0)
-   return status;
-   }
driver_suspended = true;
spin_lock_irq(usbhid-lock);
set_bit(HID_SUSPENDED, usbhid-iofl);
spin_unlock_irq(usbhid-lock);
-   if (usbhid_wait_io(hid)  0) {
+   if (usbhid_wait_io(hid)  0)
status = -EIO;
-   goto failed;
-   }
}
 
hid_cancel_delayed_stuff(usbhid);
@@ -1544,7 +1540,7 @@ static int hid_suspend(struct usb_interface *intf, 
pm_message_t message)
goto failed;
}
dev_dbg(intf-dev, suspend\n);
-   return 0;
+   return status;
 
  failed:
hid_resume_common(hid, driver_suspended);
-- 
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

[PATCH 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep

If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.

Cc: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/net/usb/cdc_mbim.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 248d2dc..da83546 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -338,7 +338,7 @@ static int cdc_mbim_suspend(struct usb_interface *intf, 
pm_message_t message)
 
if (intf == ctx-control  info-subdriver  info-subdriver-suspend)
ret = info-subdriver-suspend(intf, message);
-   if (ret  0)
+   if (ret  0  PMSG_IS_AUTO(msg))
usbnet_resume(intf);
 
 error:
-- 
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

[PATCH 5/7] usbnet: smsc95xx: don't recover device if suspend fails in system sleep

If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.

Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/net/usb/smsc95xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index e6d2dea..a0c5478 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1660,7 +1660,7 @@ static int smsc95xx_suspend(struct usb_interface *intf, 
pm_message_t message)
ret = smsc95xx_enter_suspend0(dev);
 
 done:
-   if (ret)
+   if (ret  PMSG_IS_AUTO(msg))
usbnet_resume(intf);
return ret;
 }
-- 
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

[PATCH 6/7] usbnet: smsc75xx: don't recover device if suspend fails in system sleep

If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.

Cc: Steve Glendinning steve.glendinn...@shawell.net
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/net/usb/smsc75xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
index 9abe517..f65c506 100644
--- a/drivers/net/usb/smsc75xx.c
+++ b/drivers/net/usb/smsc75xx.c
@@ -2011,7 +2011,7 @@ static int smsc75xx_suspend(struct usb_interface *intf, 
pm_message_t message)
ret = smsc75xx_enter_suspend0(dev);
 
 done:
-   if (ret)
+   if (ret  PMSG_IS_AUTO(msg))
usbnet_resume(intf);
return ret;
 }
-- 
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

[PATCH 7/7] usbnet: qmi_wwan: don't recover device if suspend fails in system sleep

If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this patch doesn't recover device under this situation.

Cc: Bjørn Mork bj...@mork.no
Signed-off-by: Ming Lei ming@canonical.com
---
 drivers/net/usb/qmi_wwan.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index efb5c7c..fce18be 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -294,7 +294,7 @@ static int qmi_wwan_suspend(struct usb_interface *intf, 
pm_message_t message)
 
if (intf == info-control  info-subdriver  
info-subdriver-suspend)
ret = info-subdriver-suspend(intf, message);
-   if (ret  0)
+   if (ret  0   PMSG_IS_AUTO(msg))
usbnet_resume(intf);
 err:
return ret;
-- 
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

[PATCH 1/1] usb: gadget: fsl_udc_core: Use module_platform_driver_probe macro

module_platform_driver_probe() eliminates the boilerplate and simplifies
the code.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Cc: Li Yang le...@freescale.com
---
 drivers/usb/gadget/fsl_udc_core.c |   16 +---
 1 files changed, 1 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/fsl_udc_core.c 
b/drivers/usb/gadget/fsl_udc_core.c
index 04d5fef..f523897 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2747,21 +2747,7 @@ static struct platform_driver udc_driver = {
},
 };
 
-static int __init udc_init(void)
-{
-   printk(KERN_INFO %s (%s)\n, driver_desc, DRIVER_VERSION);
-   return platform_driver_probe(udc_driver, fsl_udc_probe);
-}
-
-module_init(udc_init);
-
-static void __exit udc_exit(void)
-{
-   platform_driver_unregister(udc_driver);
-   printk(KERN_WARNING %s unregistered\n, driver_desc);
-}
-
-module_exit(udc_exit);
+module_platform_driver_probe(udc_driver, fsl_udc_probe);
 
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_AUTHOR(DRIVER_AUTHOR);
-- 
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: [PATCH 0/7] USB: don't recover device if suspend fails in system sleep

On Tue, Mar 5, 2013 at 12:01 PM, Ming Lei ming@canonical.com wrote:
 Hi,

 This patch adds comments on interface driver suspend callback
 to emphasize that the failure return value is ignored by
 USB core in system sleep context, so do not try to recover
 device for this case, otherwise the URB traffic scheduled
 in recovery of failure path may cross system sleep, and may
 cause problems.

 Also fixes the USB serial, HID and several usbnet drivers
 which may recover device in suspend failure path of system sleep.

Sorry, this patches have compile problem, so please don't apply them,
and I will send v1 later.


Thanks,
--
Ming Lei
--
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/7] USB: don't recover device if suspend fails in system sleep

Ming Lei ming@canonical.com writes:

 Hi,

 This patch adds comments on interface driver suspend callback
 to emphasize that the failure return value is ignored by
 USB core in system sleep context, so do not try to recover
 device for this case, otherwise the URB traffic scheduled
 in recovery of failure path may cross system sleep, and may
 cause problems.

Well, an unexpected error did happen so problems are to be expected,
yes.

 Also fixes the USB serial, HID and several usbnet drivers
 which may recover device in suspend failure path of system sleep.

I believe all of these are wrong unless you have any real bug which is
fixed by this.

All these drivers suspend in multiple steps, where each step can
fail. If a later step fails then they revert any previously successful
step before returning the failure, thereby ensuring that the
device/driver state when suspend returns is consistently either
suspended or resumed.

The error recovery they do in suspend is not about preventing suspend at
all.  It is about ensuring that that the driver and device is in a
consistent state, which is resumed if suspend fails.

Your patch set make the drivers return from suspend in some intermediate
state, where the device and/or driver is neither suspended nor resumed.
This is wrong.  You still did not necessarily kill all URBs, but you
killed some of them.  What is resume() going to do then?

I am going to NAK the cdc_mbim and qmi_wwan pacthes unless you can
convince me that we need to add a partly-suspended state for the
system suspend error case.  In which case the patch will need to include
the corresponding resume fix for the partly-suspended state.


Bjørn
--
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 4/7] usbnet: cdc_mbim: don't recover device if suspend fails in system sleep

Ming Lei ming@canonical.com writes:

 If suspend callback fails in system sleep context, usb core will
 ignore the failure and let system sleep go ahead further, so
 this patch doesn't recover device under this situation.

 Cc: Bjørn Mork bj...@mork.no
 Signed-off-by: Ming Lei ming@canonical.com
 ---
  drivers/net/usb/cdc_mbim.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
 index 248d2dc..da83546 100644
 --- a/drivers/net/usb/cdc_mbim.c
 +++ b/drivers/net/usb/cdc_mbim.c
 @@ -338,7 +338,7 @@ static int cdc_mbim_suspend(struct usb_interface *intf, 
 pm_message_t message)
  
   if (intf == ctx-control  info-subdriver  info-subdriver-suspend)
   ret = info-subdriver-suspend(intf, message);
 - if (ret  0)
 + if (ret  0  PMSG_IS_AUTO(msg))
   usbnet_resume(intf);
  
  error:

NAK. We if the device cannot suspend, then it cannot do suspend halfways
either. Whether the caller will ignore the error or not, is irrelevant.


Bjørn
--
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 7/7] usbnet: qmi_wwan: don't recover device if suspend fails in system sleep