Subject: [PATCH 000/100] usb: gadget: big patch bomb

Hi folks,

sorry fort he patch bomb, but I have been busy lately and I pretty
much forgot which patches I had already sent and which needed to be
sent again, so I'm sending everything I have already which *will be*
queued for v3.10 merge window.

Please go over the patches and scream if you see anything wrong. I have
just pushed the entire series to a branch called 'testing' on my git
tree.

Again, sorry for the patch bomb, but overall the diffstat looks good;
deleting 152 lines is always good.

Felipe Balbi (99):
  usb: gadget: udc-core: allow udc class register gadget device
  usb: dwc3: gadget: let udc-core manage gadget->dev
  usb: musb: gadget: let udc-core manage gadget-dev
  usb: gadget: omap_udc: let udc-core manage gadget->dev
  usb: gadget: amd5536udc: let udc-core manage gadget->dev
  usb: gadget: at91_udc: let udc-core manage gadget->dev
  usb: gadget: atmel_usba_udc: let udc-core manage gadget->dev
  usb: gadget: bcm63xx_udc: let udc-core manage gadget->dev
  usb: gadget: dummy_hcd: let udc-core manage gadget->dev
  usb: gadget: fsl_qe_udc: let udc-core manage gadget->dev
  usb: gadget: fsl_udc_core: let udc-core manage gadget->dev
  usb: gadget: fusb300_udc: let udc-core manage gadget->dev
  usb: gadget: goku_udc: let udc-core manage gadget->dev
  usb: gadget: imx_udc: let udc-core manage gadget->dev
  usb: gadget: lpc32xx_udc: let udc-core manage gadget->dev

WEBMASTER EMAIL ACCOUNT UPGRADE

-- 
WEBMASTER EMAIL ACCOUNT UPGRADE

 Information Technology Services (ITS) are currently updating our new
website accounts. This will provide you the ability to store a greatly
Increased amount of e-mail correspondence in your e-mail account and
also reduce spam emails that is received in your email on the daily
basis. Your account has been selected, as one of the accounts that are
to be upgraded. Please click the link below and follow the instruction
to upgrade your email account

 CLICK HERE: http://glacierdesign.ca/phpform/forms/form1.html

 The new minimum quota level for e-mail accounts will be set to 2 G.

 © Copyright 2012  |  WEBMASTER EMAIL HELP DESK • • ALL RIGHTS RESERVED.

                                !!!     WARNING    !!!
 Do not respond to Emails Instructing you to send your email password
as this is a phishing attempt. Failure to log out will allow others to
access your account. Closing the browser window does NOT log you out
properly. To log out, please click one of the "Log out" icons in the
browser window.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bug in xHCI command cancellation

Hi Elric,

I was looking at the xHCI command cancellation code, and I realized that
xhci_cancel_cmd() calls xhci_abort_cmd_ring() with the xHCI spinlock
held.  That function spins for up to 5 seconds, waiting for the command
ring running bit to be clear.

We really can't have the spinlock held for that long, since other things
like port status change events can cause the interrupt handler to be
called (which would attempt to acquire the spinlock).

Would it be OK to drop the spinlock in xhci_abort_cmd_ring() before
spinning on the CRR?  Or were you trying to protect some other xHCI
structures/registers with the lock while you waited to abort the command
ring?

It's commit ID b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add
aborting command ring function" if you need to refresh your memory.

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

Testing for hardware bug in EHCI controllers

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

[PATCH 1/4] usb: gadget: s3c2410: fix gadget->dev registration

Whenever ->udc_start() gets called, gadget driver
has already being bound to the udc controller, which
means that gadget->dev had to be already initialized
and added to driver model.

This patch fixes s3c2410 mistake.

Signed-off-by: Felipe Balbi <balbi@...>
---
 drivers/usb/gadget/s3c2410_udc.c | 26 +++++++++++---------------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c
index fc07b43..9404858 100644
--- a/drivers/usb/gadget/s3c2410_udc.c
+++ b/drivers/usb/gadget/s3c2410_udc.c
 <at>  <at>  -1669,7 +1669,6  <at>  <at>  static int s3c2410_udc_start(struct usb_gadget *g,
 		struct usb_gadget_driver *driver)
 {
 	struct s3c2410_udc *udc = to_s3c2410(g)
-	int		retval;

 	dprintk(DEBUG_NORMAL, "%s() '%s'\n", __func__, driver->driver.name);

 <at>  <at>  -1677,22 +1676,10  <at>  <at>  static int s3c2410_udc_start(struct usb_gadget *g,
 	udc->driver = driver;
 	udc->gadget.dev.driver = &driver->driver;

-	/* Bind the driver */
-	retval = device_add(&udc->gadget.dev);

Hi

Hello,

My name is Fernandez Flor, I am the branch manager of Banco pichincha Quito Ecuador.
I have packaged a financial transaction that will benefit both of us, which
involves three million seven hundred and fifty thousand dollar $3,750.000.00.
Mean While you will have 35% of the total fund after the transaction.

If you accept this offer to work with me i will give you details on how we can
achieve it successfully. Please contact me with this email address:
fernanflo@...

Mr.Fernandez Flor

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

[RESEND PATCH] USB: xhci - fix bit definitions for IMAN register

According to XHCI specification (5.5.2.1) the IP is bit 0 and IE is bit 1
of IMAN register. Previously their definitions were reversed.

Even though there are no ill effects being observed from the swapped
definitions (because IMAN_IP is RW1C and in legacy PCI case we come in
with it already set to 1 so it was clearing itself even though we were
setting IMAN_IE instead of IMAN_IP), we should still correct the values.

Signed-off-by: Dmitry Torokhov <dtor@...>
---

 drivers/usb/host/xhci.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index f791bd0..2c510e4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
 <at>  <at>  -206,8 +206,8  <at>  <at>  struct xhci_op_regs {
 /* bits 12:31 are reserved (and should be preserved on writes). */

 /* IMAN - Interrupt Management Register */
-#define IMAN_IP		(1 << 1)
-#define IMAN_IE		(1 << 0)
+#define IMAN_IE		(1 << 1)
+#define IMAN_IP		(1 << 0)

 /* USBSTS - USB status - status bitmasks */
 /* HC not running - set to 1 when run/stop bit is cleared. */
--

[PATCH] usb: otg: use try_module_get in all usb_get_phy functions and add missing module_put

From: Marc Kleine-Budde <mkl@...>

In patch "5d3c28b usb: otg: add device tree support to otg library"
devm_usb_get_phy_by_phandle() was added. It uses try_module_get() to lock the
phy driver in memory. The corresponding module_put() is missing in that patch.

This patch adds try_module_get() to usb_get_phy() and usb_get_phy_dev().
Further the missing module_put() is added to usb_put_phy().

Reviewed-by: Kishon Vijay Abraham I <kishon@...>
Acked-by: Felipe Balbi <balbi@...>
Signed-off-by: Marc Kleine-Budde <mkl@...>
Signed-off-by: Michael Grzeschik <m.grzeschik@...>
---
Hello,

this patch got lost somehow, it applies to current linus/master (pre v3.9-rc1).
Please apply.

regards,
Marc & Michael

 drivers/usb/otg/otg.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index e181439..2bd03d2 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
 <at>  <at>  -130,7 +130,7  <at>  <at>  struct usb_phy *usb_get_phy(enum usb_phy_type type)

[PATCH 0/2] usb: gadget: pxa27x_udc: drop ARCH dependency

This one was easy enough to do, but there are still quite a few left.

$ git grep -e "depends on ARCH" drivers/usb/gadget/Kconfig
drivers/usb/gadget/Kconfig:     depends on ARCH_AT91
drivers/usb/gadget/Kconfig:     depends on ARCH_LPC32XX
drivers/usb/gadget/Kconfig:     depends on ARCH_OMAP1
drivers/usb/gadget/Kconfig:     depends on ARCH_MXC
drivers/usb/gadget/Kconfig:     depends on ARCH_S3C24XX
drivers/usb/gadget/Kconfig:     depends on ARCH_S3C24XX

include the original UDC for the OMAP1 SoC. I wonder if anyone
still cares about that...

Anyway, I don't have the HW so these two patches have been
build-tested only. Please make sure to Test as this will go
in v3.10 if I don't hear any complaints.

cheers

Felipe Balbi (2):
  usb: gadget: pxa27x_udc: drop ARCH_PXA dependency
  usb: gadget: pxa27x_udc: switch over to module_platform_driver

 drivers/usb/gadget/Kconfig      |  1 -
 drivers/usb/gadget/pxa27x_udc.c | 26 +++++---------------------
 2 files changed, 5 insertions(+), 22 deletions(-)

--

-- 
1.8.1.rc1.5.g7e0651a

[PATCH] usb: chipidea: register debugging sysfs on our device

Don't register anything non-generic under
the gadget's device as we don't really *own*
it.

Signed-off-by: Felipe Balbi <balbi@...>
---

Hi Alex,

please take a look at this patch, if you don't reply to it
I will take it through my tree for this -rc cycle. I have sent
few weeks ago and didn't get a review.

cheers

 drivers/usb/chipidea/udc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2f45bba..f64fbea 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
 <at>  <at>  -1767,7 +1767,7  <at>  <at>  static int udc_start(struct ci13xxx *ci)
 		goto put_transceiver;
 	}

-	retval = dbg_create_files(&ci->gadget.dev);
+	retval = dbg_create_files(ci->dev);
 	if (retval)
 		goto unreg_device;

[PATCH] USB: remove incorrect __exit markups

Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe() which specifically disables sysfs bind/unbind
attributes.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...>
---
 drivers/usb/host/ehci-mxc.c    | 2 +-
 drivers/usb/host/ehci-orion.c  | 4 ++--
 drivers/usb/host/ehci-sh.c     | 4 ++--
 drivers/usb/otg/isp1301_omap.c | 4 ++--
 drivers/usb/otg/twl4030-usb.c  | 4 ++--
 drivers/usb/otg/twl6030-usb.c  | 4 ++--
 drivers/usb/phy/mv_u3d_phy.c   | 2 +-
 7 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index dedb80b..85c99c3 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
 <at>  <at>  -199,7 +199,7  <at>  <at>  err_alloc:
 	return ret;
 }

-static int __exit ehci_mxc_drv_remove(struct platform_device *pdev)
+static int ehci_mxc_drv_remove(struct platform_device *pdev)
 {
 	struct mxc_usbh_platform_data *pdata = pdev->dev.platform_data;
 	struct usb_hcd *hcd = platform_get_drvdata(pdev);