RE: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature add

[Neil Zhang]

Hi Balbi,

> -Original Message-
> From: Neil Zhang
> Sent: 2012年7月25日 19:52
> To: Neil Zhang; ba...@ti.com; gre...@linuxfoundation.org
> Cc: Chao Xie; khoroshi...@ispras.ru; linux-usb@vger.kernel.org
> Subject: RE: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature
> add
> 
> Hi Balbi,
> 
> > -Original Message-
> > From: Neil Zhang
> > Sent: 2012年7月19日 22:48
> > To: Neil Zhang; ba...@ti.com; gre...@linuxfoundation.org
> > Cc: Chao Xie; khoroshi...@ispras.ru; linux-usb@vger.kernel.org
> > Subject: RE: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature
> > add
> >
> > Hi Balbi,
> >
> > > -Original Message-
> > > From: Neil Zhang [mailto:zhan...@marvell.com]
> > > Sent: 2012年7月10日 10:07
> > > To: ba...@ti.com; gre...@linuxfoundation.org
> > > Cc: Chao Xie; khoroshi...@ispras.ru; linux-usb@vger.kernel.org;
> Neil
> > > Zhang
> > > Subject: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature
> add
> > >
> > > This patch set will add ISO support for mv_udc and do some bug fix.
> > >
> > > ChangeLog:
> > > V2:
> > > 1. Fix some syntax error in comments.
> > > 2. Use usb_endpoint_xfer_isoc instead of redundant code, thanks
> > Sergei.
> > >
> > > Chao Xie (1):
> > >   usb: gadget: mv_udc: add iso support
> > >
> > > Neil Zhang (5):
> > >   usb: gadget: mv_udc: reduce the delay interval
> > >   usb: gadget: mv_udc: remove unused code
> > >   usb: gadget: mv_udc: avoid sleeping on spinlock
> > >   usb: gadget: mv_udc: enable stream mode
> > >   usb: gadget: mv_udc: fix boot up hang
> > >
> > > Yunfan Zhang (1):
> > >   usb: gadget: mv_udc: fix hang when shutdown
> > >
> > >  drivers/usb/gadget/mv_udc_core.c |   85
> +++-
> > --
> > > ---
> > >  1 files changed, 62 insertions(+), 23 deletions(-)
> > >
> > > --
> > > 1.7.4.1
> >
> > Would you please pay your time to review these patches?
> > Thanks.
> >
> > Best Regards,
> > Neil Zhang
> 
> Would you please help to review these patches?
> Thanks.
> 
> Best Regards,
> Neil Zhang

Would you please help to review these patches?
Thanks very much.

Best Regards,
Neil Zhang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{焙柒��^n�r■�z���h�ㄨ��&Ⅷ�G���h�(�茛j"���m赇z罐��帼f＂�h���~�m�

Re: [PATCH 3/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Oliver Neukum]

On Wednesday 01 August 2012 23:14:03 Lan Tianyu wrote:
> On 2012/8/1 22:48, Oliver Neukum wrote:

> > Strictly speaking, no. It is possible that there are devices that may
> > do something bad in case of a reset, but sometimes work well. In
> > such cases we should try.
> Do you mean some devices of this kind will not morph after reset? I a 
> little confuse since in my mind that all such kind devices will morph
> after reset.

The point is that we don't know. User space has set a flag for reasons
of its own. If user space wants to clear the persist attribute it can do
so.

Regards
Oliver

--
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/8] USB:support the new interfaces of Huawei Data Card devices in option driver

[Fangxiaozhi (Franko)]

From: fangxiaozhi 
1. This patch is based on the kernel of 3.5
2. In this patch, we add new micro for matching the series USB devices with 
vendor ID and interface information.
3. In this patch, we add new declarations into option.c to support the new 
interfaces of Huawei Data Card devices. And at the same time, remove the 
redundant declarations from option.c.
Signed-off-by: fangxiaozhi 
 ---

--- test/linux-3.5/include/linux/usb.h  2012-07-22 04:58:29.0 +0800
+++ linux-3.5/include/linux/usb.h   2012-07-26 14:40:40.0 +0800
@@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
.bInterfaceClass = (cl), \
.bInterfaceSubClass = (sc), \
.bInterfaceProtocol = (pr)
+/**
+ *  * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a 
class of usb interfaces, but independent of product ID
+ *  @vend: the 16 bit USB Vendor ID
+ *  @cl: bInterfaceClass value
+ *  @sc: bInterfaceSubClass value
+ *  @pr: bInterfaceProtocol value
+ *
+ *  This macro is used to create a struct usb_device_id that matches a
+ *  series of devices with a vendor ID and a specific class of interfaces.
+ *
+ *  This is especially useful when explicitly matching the specific interface 
for series of different devices with
+ *  the same vendor.
+ */
+
+#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \
+   .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+   | USB_DEVICE_ID_MATCH_VENDOR, \
+   .idVendor = (vend), \
+   .bInterfaceClass = (cl), \
+   .bInterfaceSubClass = (sc), \
+   .bInterfaceProtocol = (pr)

 /* --- */

--- test/linux-3.5/drivers/usb/serial/option.c  2012-07-22 04:58:29.0 
+0800
+++ linux-3.5/drivers/usb/serial/option.c   2012-07-26 15:51:30.0 
+0800
@@ -80,85 +80,9 @@ static void option_instat_callback(struc
 #define OPTION_PRODUCT_GTM380_MODEM0x7201

 #define HUAWEI_VENDOR_ID   0x12D1
-#define HUAWEI_PRODUCT_E6000x1001
-#define HUAWEI_PRODUCT_E2200x1003
-#define HUAWEI_PRODUCT_E220BIS 0x1004
-#define HUAWEI_PRODUCT_E1401   0x1401
-#define HUAWEI_PRODUCT_E1402   0x1402
-#define HUAWEI_PRODUCT_E1403   0x1403
-#define HUAWEI_PRODUCT_E1404   0x1404
-#define HUAWEI_PRODUCT_E1405   0x1405
-#define HUAWEI_PRODUCT_E1406   0x1406
-#define HUAWEI_PRODUCT_E1407   0x1407
-#define HUAWEI_PRODUCT_E1408   0x1408
-#define HUAWEI_PRODUCT_E1409   0x1409
-#define HUAWEI_PRODUCT_E140A   0x140A
-#define HUAWEI_PRODUCT_E140B   0x140B
-#define HUAWEI_PRODUCT_E140C   0x140C
-#define HUAWEI_PRODUCT_E140D   0x140D
-#define HUAWEI_PRODUCT_E140E   0x140E
-#define HUAWEI_PRODUCT_E140F   0x140F
-#define HUAWEI_PRODUCT_E1410   0x1410
-#define HUAWEI_PRODUCT_E1411   0x1411
-#define HUAWEI_PRODUCT_E1412   0x1412
-#define HUAWEI_PRODUCT_E1413   0x1413
-#define HUAWEI_PRODUCT_E1414   0x1414
-#define HUAWEI_PRODUCT_E1415   0x1415
-#define HUAWEI_PRODUCT_E1416   0x1416
-#define HUAWEI_PRODUCT_E1417   0x1417
-#define HUAWEI_PRODUCT_E1418   0x1418
-#define HUAWEI_PRODUCT_E1419   0x1419
-#define HUAWEI_PRODUCT_E141A   0x141A
-#define HUAWEI_PRODUCT_E141B   0x141B
-#define HUAWEI_PRODUCT_E141C   0x141C
-#define HUAWEI_PRODUCT_E141D   0x141D
-#define HUAWEI_PRODUCT_E141E   0x141E
-#define HUAWEI_PRODUCT_E141F   0x141F
-#define HUAWEI_PRODUCT_E1420   0x1420
-#define HUAWEI_PRODUCT_E1421   0x1421
-#define HUAWEI_PRODUCT_E1422   0x1422
-#define HUAWEI_PRODUCT_E1423   0x1423
-#define HUAWEI_PRODUCT_E1424   0x1424
-#define HUAWEI_PRODUCT_E1425   0x1425
-#define HUAWEI_PRODUCT_E1426   0x1426
-#define HUAWEI_PRODUCT_E1427   0x1427
-#define HUAWEI_PRODUCT_E1428   0x1428
-#define HUAWEI_PRODUCT_E1429   0x1429
-#define HUAWEI_PRODUCT_E142A   0x142A
-#define HUAWEI_PRODUCT_E142B   0x142B
-#define HUAWEI_PRODUCT_E142C   0x142C
-#define HUAWEI_PRODUCT_E142D   0x142D
-#define HUAWEI_PRODUCT_E142E   0x142E
-#define HUAWEI_PRODUCT_E142F   0x142F
-#define HUAWEI_PRODUCT_E1430   0x1430
-#define HUAWEI_PRODUCT_E1431   0x1431
-#define HUAWEI_PRODUCT_E1432   0x1432
-#define HUAWEI_PRODUCT_E1433 

RE: [RFC/PATCH v3] usb: dwc3: Introduce OTG driver for dwc3

[Anton Tikhomirov]

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Ido Shayevitz
> Sent: Wednesday, August 01, 2012 11:44 PM
> To: Anton Tikhomirov
> Cc: 'Ido Shayevitz'; 'Felipe Balbi'; paul.zimmer...@synopsys.com; linux-
> u...@vger.kernel.org
> Subject: RE: [RFC/PATCH v3] usb: dwc3: Introduce OTG driver for dwc3
> 
> 
> Hi Anton,
> 
> On Tue, July 31, 2012 11:27 pm, Anton Tikhomirov wrote:
> > Hi Ido,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Ido Shayevitz
> >> Sent: Monday, July 30, 2012 10:16 PM
> >> To: Anton Tikhomirov
> >> Cc: 'Ido Shayevitz'; 'Felipe Balbi'; linux-usb@vger.kernel.org
> >> Subject: RE: [RFC/PATCH v3] usb: dwc3: Introduce OTG driver for dwc3
> >>
> >> Hi Anton,
> >>
> >> On Mon, July 30, 2012 5:25 am, Anton Tikhomirov wrote:
> >> > Hi Ido,
> >> >
> >> >> >
> >> >> > You activate sm only if gadget and host are ready. At the same
> >> time,
> >> >> > in dwc3_otg_interrupt() you schedule work if interrupt happens. In
> >> >> > situation
> >> >> > when host is not set yet, but cable is plugged, we will have
> >> unwanted
> >> >> sm
> >> >> > activation
> >> >> > (in interrupt handler) and, as a consequence, repeating error
> >> "unable
> >> >> to
> >> >> > start A-device\n"
> >> >> > in dwc3_otg_sm_work().
> >> >>
> >> >> Host and gadget should set themselves to the otg on drivers probe,
> in
> >> >> boot
> >> >> time. So cable connect happens later.
> >> >> If the scenario you describe does happen it means that the xHCI
> >> driver
> >> >> was
> >> >> not loaded into the kernel, but cable with micro-A was plugged into
> >> your
> >> >> device, so need add host support to the menuconfig.
> >> >> It should be enough to select in the menuconfig CONFIG_USB and
> >> >> CONFIG_USB_XHCI_HCD.
> >> >
> >> > Agree. But what if my controller supports DRD mode, but I _want_ to
> >> keep
> >> > this
> >> > option (XHCI support) off, for any reason. By the way, it seems we
> >> will
> >> > have
> >> > similar effect when micro-A cable is plugged after
> > otg_set_host(phy->otg,
> >> > NULL)
> >> > call. Of course such situations are rare.
> >> >
> >>
> >> OK, so I will avoid the re-schedule of the sm_work after this error
> will
> >> be printed (so will be printed once...)
> >> Thanks...
> >
> > One more thing. Currently the work is first time scheduled in two cases:
> > when
> > interrupt happens or both, peripheral and host, were set. If host is not
> > set
> > (and probably won't be) the work will _not_ be scheduled (and peripheral
> > will
> > not start) till we connect and then disconnect micro-A cable. In other
> > words:
> > we should be able to use peripheral even if host is not supported (and
> > vice
> > versa?). What's your opinion?
> 
> The idea behind schedule the work after both are set, is that we don't
> want a case that we scheduled the work after only the gadget was set but
> the ID pin is zero. In this case we will get wasted run of work state
> machine.

How about to stop the state machine after the first error "unable to start
A-device" (in OTG_STATE_A_IDLE). It will be restarted (in irq handler) when
user unplugs the micro-A cable.

> If host is not set, we will start the peripheral on cable connect, as you

What cable type do you mean?

If type is micro-A, then we will have otg event (id 1->0) and we can start
peripheral as soon as user unplugs the cable (id 0->1). In this case, it's
a little bit strange, that user needs to plug micro-A cable to start
peripheral (read machine).

If type is micro-B, then how can we catch this event? (Do you remember:
host is not set, preventing us to start machine, and no interrupt since
there
is no id transition). Now dwc3_gadget_run_stop() is called from
dwc3_gadget_pullup() only if dwc->vbus_active is 1, and from
dwc3_gadget_vbus_session() which won't be called (and consequently
vbus_active
won't be set) since machine is not running.

> said, and if ID pin is 1. When we start the peripheral we actually just
> turn on the run stop bit, while the dwc3 gadget driver was already up and
> allocated its needed memory, so there shouldn't be problem to wait until
> cable connect...
> 
> >>
> >> >> But if your controller DWC_MODE (see core.c) does not support DRD,
> or
> >> >> the
> >> >> cable plugged in is micro-B then this error should not be printed
> >> >> eventhough the host was not set.
> >> >>
> >> >> >> >> + } else {
> >> >> >> >> + if (otg->phy->state == OTG_STATE_A_HOST) {
> >> >> >> >> + dwc3_otg_start_host(otg, 0);
> >> >> >> >> + otg->host = NULL;
> >> >> >> >> + otg->phy->state = OTG_STATE_UNDEFINED;
> >> >> >> >> + schedule_work(&dotg->sm_work);
> >> >> >> >> + } else {
> >> >> >> >> + otg->host = NULL;
> >> >> >> >> + }
> >> >> >> >> + }
> >> >> >> >> +
> >> >> >> >> + return 

[PATCH RFC] usb: musb: use DMA mode 1 whenever possible

[Roger Quadros]

Do not rely on any hints from gadget drivers and use DMA mode 1
whenever we expect more data than the endpoint's packet size and
have not yet received a short packet.

The last packet if short is always transferred using DMA mode 0.

This patch fixes USB throughput issues in mass storage mode for
host to device transfers.

Signed-off-by: Roger Quadros 
---
 drivers/usb/musb/musb_gadget.c |   30 --
 1 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f7194cf..9c94655 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
musb_request *req)
len = musb_readw(epio, MUSB_RXCOUNT);
 
/*
-* Enable Mode 1 on RX transfers only when short_not_ok flag
-* is set. Currently short_not_ok flag is set only from
-* file_storage and f_mass_storage drivers
+*  use mode 1 only if we expect data larger than ep packet_sz
+*  and we have not yet received a short packet
 */
-
-   if (request->short_not_ok && len == musb_ep->packet_sz)
+   if ((request->length - request->actual > musb_ep->packet_sz) &&
+   (len >= musb_ep->packet_sz))
use_mode_1 = 1;
else
use_mode_1 = 0;
@@ -727,27 +726,6 @@ static void rxstate(struct musb *musb, struct musb_request 
*req)
c = musb->dma_controller;
channel = musb_ep->dma;
 
-   /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
-* mode 0 only. So we do not get endpoint interrupts due to DMA
-* completion. We only get interrupts from DMA controller.
-*
-* We could operate in DMA mode 1 if we knew the size of the tranfer
-* in advance. For mass storage class, request->length = what the host
-* sends, so that'd work.  But for pretty much everything else,
-* request->length is routinely more than what the host sends. For
-* most these gadgets, end of is signified either by a short packet,
-* or filling the last byte of the buffer.  (Sending extra data in
-* that last pckate should trigger an overflow fault.)  But in mode 1,
-* we don't get DMA completion interrupt for short packets.
-*
-* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
-* to get endpoint interrupt on every DMA req, but that didn't seem
-* to work reliably.
-*
-* REVISIT an updated g_file_storage can set req->short_not_ok, which
-* then becomes usable as a runtime "use mode 1" hint...
-*/
-
/* Experimental: Mode1 works with mass storage 
use cases */
if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
-- 
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: OMAP3: USB: EHCI broken on 3.5?

[Joe Woodward]

(Adding in the USB mailing list)...

It seems that the clocks are registered with a .dev_id of "usbhs_omap" on 
OMAP3xxx, but not OMAP4xxx, and that this causes the clk_get() in ehci-omap.c 
to fail.

The following fixes the problem for me, but I've no idea if this is the correct 
fix or not?

(sorry if the patch is mangled, using a naff webmail client).

--- a/arch/arm/mach-omap2/clock3xxx_data.c  2012-07-21 21:58:29.0 
+0100
+++ b/arch/arm/mach-omap2/clock3xxx_data.c  2012-08-02 09:07:58.205633679 
+0100
@@ -3391,15 +3391,15 @@
CLK(NULL,   "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK(NULL,   "usbhost_ick",  &usbhost_ick,   CK_3430ES2PLUS | 
CK_AM35XX | CK_36XX),
CLK("usbhs_omap",   "usbhost_ick",  &usbhost_ick,   CK_3430ES2PLUS 
| CK_AM35XX | CK_36XX),
-   CLK("usbhs_omap",   "utmi_p1_gfclk",&dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "utmi_p2_gfclk",&dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "xclk60mhsp1_ck",   &dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "xclk60mhsp2_ck",   &dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "usb_host_hs_utmi_p1_clk",  &dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "usb_host_hs_utmi_p2_clk",  &dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "usb_tll_hs_usb_ch0_clk",   &dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "usb_tll_hs_usb_ch1_clk",   &dummy_ck,  
CK_3XXX),
-   CLK("usbhs_omap",   "init_60m_fclk",&dummy_ck,  
CK_3XXX),
+   CLK(NULL,   "utmi_p1_gfclk",&dummy_ck,  CK_3XXX),
+   CLK(NULL,   "utmi_p2_gfclk",&dummy_ck,  CK_3XXX),
+   CLK(NULL,   "xclk60mhsp1_ck",   &dummy_ck,  CK_3XXX),
+   CLK(NULL,   "xclk60mhsp2_ck",   &dummy_ck,  CK_3XXX),
+   CLK(NULL,   "usb_host_hs_utmi_p1_clk",  &dummy_ck,  
CK_3XXX),
+   CLK(NULL,   "usb_host_hs_utmi_p2_clk",  &dummy_ck,  
CK_3XXX),
+   CLK(NULL,   "usb_tll_hs_usb_ch0_clk",   &dummy_ck,  
CK_3XXX),
+   CLK(NULL,   "usb_tll_hs_usb_ch1_clk",   &dummy_ck,  
CK_3XXX),
+   CLK(NULL,   "init_60m_fclk",&dummy_ck,  CK_3XXX),
CLK(NULL,   "usim_fck", &usim_fck,  CK_3430ES2PLUS | 
CK_36XX),
CLK(NULL,   "gpt1_fck", &gpt1_fck,  CK_3XXX),
CLK(NULL,   "wkup_32k_fck", &wkup_32k_fck,  CK_3XXX),


Cheers,
Joe

-Original Message-
From: "Joe Woodward" 
To: "linux-o...@vger.kernel.org" 
Date: Tue, 31 Jul 2012 13:42:07 +0100
Subject: OMAP3: USB: EHCI broken on 3.5?

> I have a GUMSTIX Overo AirSTORM (AM3703-based).
> 
> When running a 3.4 kernel the USB host works just fine!
> 
> However when switching to 3.5 I get a few new warning messages and USB
> host no longer works.
> 
> dmesg log after successfully loading the module (modprobe echi-hcd) on
> 3.4:
> [   23.424499] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
> Driver
> [   23.431427] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
> [   23.431732] ehci-omap ehci-omap.0: failed to get ehci port1
> regulator
> [   23.431762] gpio_request: gpio-183 (USB2 PHY reset) status -16
> [   24.433471] ehci-omap ehci-omap.0: phy reset operation timed out
> [   24.433502] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0
> cc=1 pcc=3 ordered ports=3
> [   24.433532] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1
> uframes 256/512/1024 park
> [   24.433532] ehci-omap ehci-omap.0: reset command 0080b02  park=3
> ithresh=8 period=1024 Reset HALT
> [   24.433563] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> [   24.440063] ehci-omap ehci-omap.0: new USB bus registered, assigned
> bus number 1
> [   24.448120] ehci-omap ehci-omap.0: park 0
> [   24.448181] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
> [   24.454162] ehci-omap ehci-omap.0: init command 0010005 (park)=0
> ithresh=1 period=512 RUN
> [   24.474517] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> [   24.481597] usb usb1: default language 0x0409
> [   24.481658] usb usb1: udev 1, busnum 1, minor = 0
> [   24.481689] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002
> [   24.488830] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [   24.496398] usb usb1: Product: OMAP-EHCI Host Controller
> [   24.501953] usb usb1: Manufacturer: Linux 3.4.0 ehci_hcd
> [   24.507537] usb usb1: SerialNumber: ehci-omap.0
> [   24.528747] usb usb1: usb_probe_device
> [   24.528778] usb usb1: configuration #1 chosen from 1 choice
> [   24.529479] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [   24.530212] hub 1-0:1.0: usb_probe_interface
> [   24.530242] hub 1-0:1.0: usb_probe_interface - got id
> [   24.530303] hub 1-0:1.0: USB hub found
> [   24.534362] hub 1-0:1.0: 3 ports detected
> [   24.538635] hub 1-0:1.0: standalone hub
> [   24.5

[PATCH] drivers: usb: musb: cleanup while removing musb omap glue driver

[Kishon Vijay Abraham I]

No functional change. Just replaced the call to platform_device_del and
platform_device_put with platform_device_unregister.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/omap2430.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..392fc7a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -509,8 +509,7 @@ static int __devexit omap2430_remove(struct platform_device 
*pdev)
struct omap2430_glue*glue = platform_get_drvdata(pdev);
 
cancel_work_sync(&glue->omap_musb_mailbox_work);
-   platform_device_del(glue->musb);
-   platform_device_put(glue->musb);
+   platform_device_unregister(glue->musb);
 
return 0;
 }
-- 
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

new device for qmi_wwan and option Vodafone/ZTE K5006Z

[Thomas Schäfer]

uname 
next-20120730

I used the new feature

echo "vid pid" >/sys/bus/usb/drivers/qmi_wwan/new_id


dmesg

[  229.784142] usb 1-2: new high-speed USB device number 3 using ehci_hcd
[  229.919579] usb 1-2: New USB device found, idVendor=19d2, idProduct=1017
[  229.919594] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[  229.919603] usb 1-2: Product: ZTE LTE Technologies MSM
[  229.919612] usb 1-2: Manufacturer: ZTE,Incorporated
[  229.919620] usb 1-2: SerialNumber: MF821VVDFS02
[  229.963195] usbcore: registered new interface driver uas
[  229.970088] Initializing USB Mass Storage driver...
[  229.970935] scsi4 : usb-storage 1-2:1.0
[  229.971286] usbcore: registered new interface driver usb-storage
[  229.971293] USB Mass Storage support registered.
[  233.122548] usb 1-2: USB disconnect, device number 3
[  237.544186] usb 1-2: new high-speed USB device number 4 using ehci_hcd
[  237.680085] usb 1-2: New USB device found, idVendor=19d2, idProduct=1018
[  237.680099] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
[  237.680109] usb 1-2: Product: ZTE LTE Technologies MSM
[  237.680117] usb 1-2: Manufacturer: ZTE,Incorporated
[  237.680125] usb 1-2: SerialNumber: MF821VVDFS02
[  237.685547] scsi5 : usb-storage 1-2:1.4
[  238.685785] scsi 5:0:0:0: CD-ROMVodafone USB SCSI CD-ROM  2.31 
PQ: 0 ANSI: 0
[  238.686486] scsi 5:0:0:0: Attached scsi generic sg1 type 5
[  238.687799] scsi 5:0:0:1: Direct-Access Vodafone Storage  2.31 
PQ: 0 ANSI: 0
[  238.689612] sd 5:0:0:1: Attached scsi generic sg2 type 0
[  238.698683] sd 5:0:0:1: [sdb] Attached SCSI removable disk
[  238.732245] sr0: scsi-1 drive
[  238.732256] cdrom: Uniform CD-ROM driver Revision: 3.20
[  238.733775] sr 5:0:0:0: Attached scsi CD-ROM sr0
[  816.224462] usbcore: registered new interface driver cdc_wdm
[  816.232541] usbcore: registered new interface driver qmi_wwan
[  833.357135] qmi_wwan: probe of 1-2:1.0 failed with error -22
[  833.361494] qmi_wwan: probe of 1-2:1.1 failed with error -22
[  833.363390] qmi_wwan 1-2:1.2: cdc-wdm0: USB WDM device
[  833.364343] qmi_wwan 1-2:1.2: wwan0: register 'qmi_wwan' at 
usb-:00:1d.7-2, WWAN/QMI device, 62:11:db:90:77:d1
[  833.368190] qmi_wwan 1-2:1.3: cdc-wdm1: USB WDM device
[  833.369038] qmi_wwan 1-2:1.3: wwan1: register 'qmi_wwan' at 
usb-:00:1d.7-2, WWAN/QMI device, 62:11:db:90:77:d1
[  890.237836] qmi_wwan 1-2:1.2: unknown notification 32 received: index 2 len 2
[ 1732.884839] usbcore: registered new interface driver usbserial
[ 1732.884929] usbcore: registered new interface driver usbserial_generic
[ 1732.885010] USB Serial support registered for generic
[ 1732.885034] usbserial: USB Serial Driver core
[ 1732.899204] usbcore: registered new interface driver option
[ 1732.899261] USB Serial support registered for GSM modem (1-port)
[ 1819.977738] option 1-2:1.0: GSM modem (1-port) converter detected
[ 1819.978207] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
[ 1819.978476] option 1-2:1.1: GSM modem (1-port) converter detected
[ 1819.978891] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
[ 2341.856616] usb 1-2: USB disconnect, device number 4
[ 2341.857096] option1 ttyUSB0: GSM modem (1-port) converter now disconnected 
from ttyUSB0
[ 2341.857191] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[ 2341.857230] IP: [] stop_read_write_urbs+0x37/0x80 
[usb_wwan]
[ 2341.857275] PGD 0 
[ 2341.857297] Oops:  [#1] SMP 
[ 2341.857322] Modules linked in: option usb_wwan usbserial qmi_wwan usbnet 
cdc_wdm sr_mod cdrom usb_storage uas fuse af_packet ip6table_filter ip6_tables 
iptable_filter ip_tables x_tables tun edd cpufreq_conservative 
cpufreq_userspace snd_pcm_oss cpufreq_powersave snd_mixer_oss acpi_cpufreq 
mperf snd_seq 
snd_seq_device arc4 hp_wmi sparse_keymap sg uvcvideo coretemp videobuf2_core 
videodev videobuf2_vmalloc videobuf2_memops joydev microcode pcspkr i2c_i801 
lpc_ich r8169 rtl8192ce rtl8192c_common rtlwifi mac80211 snd_hda_codec_idt wmi 
battery cfg80211 rfkill ac snd_hda_intel snd_hda_codec snd_hwdep snd_pcm 
snd_timer snd soundcore snd_page_alloc uhci_hcd i915 drm_kms_helper thermal drm 
i2c_algo_bit ehci_hcd processor usbcore usb_common button video thermal_sys
[ 2341.857712] CPU 1 
[ 2341.857734] Pid: 113, comm: khubd Not tainted 3.5.0-next-20120730-1-vanilla 
#1 Hewlett-Packard HP Mini 110-3700/1584
[ 2341.857785] RIP: 0010:[]  [] 
stop_read_write_urbs+0x37/0x80 [usb_wwan]
[ 2341.857836] RSP: 0018:880037bdbb30  EFLAGS: 00010286
[ 2341.857863] RAX:  RBX:  RCX: 880063ec6228
[ 2341.857892] RDX: 88005b6d6410 RSI:  RDI: 88007b7fba10
[ 2341.857919] RBP: 880037bdbb60 R08:  R09: 
[ 2341.857947] R10:  R11: 5347203a30425355 R12: 880063d8c180
[ 2341.857974] R13: 880063d8c180 R14:  R15: 
[ 

Re: new device for qmi_wwan and option Vodafone/ZTE K5006Z

[Thomas Schäfer]

The network connection is working via wwan1 , at least with IPv4.
The LTE speed here with 8-16Mbit/s is limited by my contract, not the device.

At the moment I have problems with IPv6, but I think this is not a problem of 
the device, more a problem of my apn, which may be only accessible via 3G.

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

Re: [PATCH] usb:musb:musb_host: Handle highmem in PIO mode

[Greg KH]

On Thu, Aug 02, 2012 at 12:06:42PM +0530, Virupax Sadashivpetimath wrote:
> In case of USB bulk transfer, when himem page
> is received, the usb_sg_init function sets the
> urb transfer buffer to NULL. When such URB
> transfer is handled, kernel crashes in PIO mode.
> Handle this by mapping the highmem buffer in PIO mode.
> 
> Signed-off-by: Virupax Sadashivpetimath 
> 

Why is this not a problem in any other host controller?  Are you sure
this fix is correct?  Why do you need to modify the struct urb for this?

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 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs

[Arnd Bergmann]

On Thursday 02 August 2012, Praveen Paneri wrote:
> Yes! I understand this problem and this is the reason these patches
> were sitting in my system for couple of weeks. In a  discussion with
> Thomas an idea of using the existing regulator framework to
> enable/disable numerous PHYs came up. For example the PMU unit
> of Exynos4210 has a register set dedicated just to control USBD_PHY,
> HDMI_PHY, MIPI_PHY, DAC_PHY and more. If a regulator with
> each phy control register as LDO is written, the phy driver becomes a
> static consumer and will modify as below.

This is roughly what I had in mind, yes. The part I'm not sure about
is the subsystem to use. One could obviously express the same logic
using the clock or gpio framework, which would work but be conceptually
wrong.

Some other parts of the PMU functionality are provided through
pm-domains rather than regulators and I guess in theory it could
all be controlled through pm-domains. Maybe someone else has a better
understanding than me what the tradeoffs are here and which subsystem
should be used for the PMU.

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

RE: [PATCH] usb:musb:musb_host: Handle highmem in PIO mode

[Virupax SADASHIVPETIMATH]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, August 02, 2012 4:30 PM
> To: Virupax SADASHIVPETIMATH
> Cc: ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; 
> Praveena
> NADAHALLY
> Subject: Re: [PATCH] usb:musb:musb_host: Handle highmem in PIO mode
> 
> On Thu, Aug 02, 2012 at 12:06:42PM +0530, Virupax Sadashivpetimath wrote:
> > In case of USB bulk transfer, when himem page
> > is received, the usb_sg_init function sets the
> > urb transfer buffer to NULL. When such URB
> > transfer is handled, kernel crashes in PIO mode.
> > Handle this by mapping the highmem buffer in PIO mode.
> >
> > Signed-off-by: Virupax Sadashivpetimath 
> > 
> 
> Why is this not a problem in any other host controller? 

Problem is seen only when the RAM on the board is 1GB or more. When the urb sg 
is in highmem. 

Below crash is seen without the patch

[   50.467529] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   50.475616] pgd = c0004000
[   50.478302] [] *pgd=
[   50.481872] Internal error: Oops: 817 [#1] PREEMPT SMP ARM
[   50.546630] CPU: 0Tainted: G   O  (3.4.0+ #1)
[   50.552062] PC is at __raw_readsl+0x30/0x100
[   50.556304] LR is at 0x0
[   50.558837] pc : []lr : [<>]psr: 2193
[   50.558837] sp : c09b5c80  ip :   fp : c09b5cb4
[   50.570312] r10: db9a46c0  r9 : c0a45538  r8 : 
[   50.575531] r7 : 0002  r6 : df860028  r5 : 0200  r4 : 00010101
[   50.582031] r3 : 464c457f  r2 : 0078  r1 :   r0 : df860028
[   50.588562] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
kernel
[   50.595947] Control: 10c5787d  Table: 1bf0c04a  DAC: 0015

> Are you sure this fix is correct?

I have tested the patch on the board with the issue and it seems to work.

>  Why do you need to modify the struct urb for this?

The URB transfer may take more than 1 interrupt for the complete transfer
to store the state of sg_miter specific to urb, struct urb is used.

Thanks 
Virupax S 



--
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/3] usb: Change persist_enabled when attribute avoid_reset_quirk is modified

[Lan Tianyu]

On 2012年8月2日 14:44:12, Oliver Neukum wrote:

On Wednesday 01 August 2012 23:14:03 Lan Tianyu wrote:

On 2012/8/1 22:48, Oliver Neukum wrote:



Strictly speaking, no. It is possible that there are devices that may
do something bad in case of a reset, but sometimes work well. In
such cases we should try.

Do you mean some devices of this kind will not morph after reset? I a
little confuse since in my mind that all such kind devices will morph
after reset.


The point is that we don't know. User space has set a flag for reasons
of its own. If user space wants to clear the persist attribute it can do
so.


Ok. I get it.

Regards
Oliver





--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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 v7 02/11] usb: musb: kill global and static for multi instance

[Ravi Babu]

From: Ajay Kumar Gupta 

Moved global variable "musb_debugfs_root" and static variable
"old_state" to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.

Also removed the global variable "orig_dma_mask" and filled the
dev->dma_mask with parent device's dma_mask.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 drivers/usb/musb/musb_core.c|   22 +++---
 drivers/usb/musb/musb_core.h|4 
 drivers/usb/musb/musb_debugfs.c |8 +++-
 3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index a565fc2..e781800 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "musb_core.h"
 
@@ -1804,10 +1805,9 @@ static const struct attribute_group musb_attr_group = {
 static void musb_irq_work(struct work_struct *data)
 {
struct musb *musb = container_of(data, struct musb, irq_work);
-   static int old_state;
 
-   if (musb->xceiv->state != old_state) {
-   old_state = musb->xceiv->state;
+   if (musb->xceiv->state != musb->xceiv_old_state) {
+   musb->xceiv_old_state = musb->xceiv->state;
sysfs_notify(&musb->controller->kobj, NULL, "mode");
}
 }
@@ -2115,11 +2115,6 @@ fail0:
 /* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
  * bridge to a platform device; this driver then suffices.
  */
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
 static int __devinit musb_probe(struct platform_device *pdev)
 {
struct device   *dev = &pdev->dev;
@@ -2138,10 +2133,6 @@ static int __devinit musb_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
-#ifndef CONFIG_MUSB_PIO_ONLY
-   /* clobbered by use_dma=n */
-   orig_dma_mask = dev->dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status < 0)
iounmap(base);
@@ -2151,7 +2142,8 @@ static int __devinit musb_probe(struct platform_device 
*pdev)
 
 static int __devexit musb_remove(struct platform_device *pdev)
 {
-   struct musb *musb = dev_to_musb(&pdev->dev);
+   struct device   *dev = &pdev->dev;
+   struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb->ctrl_base;
 
/* this gets called on rmmod.
@@ -2164,9 +2156,9 @@ static int __devexit musb_remove(struct platform_device 
*pdev)
 
musb_free(musb);
iounmap(ctrl_base);
-   device_init_wakeup(&pdev->dev, 0);
+   device_init_wakeup(dev, 0);
 #ifndef CONFIG_MUSB_PIO_ONLY
-   pdev->dev.dma_mask = orig_dma_mask;
+   dma_set_mask(dev, *dev->parent->dma_mask);
 #endif
return 0;
 }
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 84436f7..5ec32b9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -450,6 +450,10 @@ struct musb {
 #ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
 #endif
+   int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+   struct dentry   *debugfs_root;
+#endif
 };
 
 static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..1d6e8af 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{  }/* Terminating Entry */
 };
 
-static struct dentry *musb_debugfs_root;
-
 static int musb_regdump_show(struct seq_file *s, void *unused)
 {
struct musb *musb = s->private;
@@ -241,7 +239,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry   *file;
int ret;
 
-   root = debugfs_create_dir("musb", NULL);
+   root = debugfs_create_dir(dev_name(musb->controller), NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
@@ -261,7 +259,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
 
-   musb_debugfs_root = root;
+   musb->debugfs_root = root;
 
return 0;
 
@@ -274,5 +272,5 @@ err0:
 
 void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
 {
-   debugfs_remove_recursive(musb_debugfs_root);
+   debugfs_remove_recursive(musb->debugfs_root);
 }
-- 
1.7.0.4

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

[PATCH v7 00/11] usb: musb: adding multi instance support

[Ravi Babu]

This series of patches adds,
a) Multi instances support in musb driver
b) DT support for musb_dsps glue layer
c) DT support for NOP transceiver

AM33xx and TI81xx has dual musb controller and has two usb PHY of same type.
This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to
get the PHY of same type. This API support is being added by Kishon's patch
discussed at [1]

The series applies to linux-omap (master branch)
+ Vaibhav baseport patches on his tree at [3]
+ Kishon's multi phy patches on Felipe's branch 'xceiv'
+ Kishon's patch on phandle at [1]
+ AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7]
+ Damodar's recent patch at [2] 

and have been tested on Beaglebone board.

1. http://marc.info/?l=linux-usb&m=134070369306112&w=2
2. http://marc.info/?l=linux-usb&m=134200284230689&w=2
3. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging
4. http://marc.info/?l=linux-usb&m=134131746111637&w=2
5. http://marc.info/?l=linux-usb&m=134131746411639&w=2
6. http://marc.info/?l=linux-usb&m=134062716011251&w=2
7. http://marc.info/?l=linux-usb&m=134061179405213&w=2

Changes from v6:
- Removed parent_pdev to get glue and used dev_get_getdrv() as per
  Felipe's comment
- use pr_debug() instead of pr_info() as per Felipe's comment
Changes from v5:
- Removed musb->id as per Felipe's comment
- used nop_ida as per Felipe's comment
Changes from v4:
- Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL()
- Fixed Felipe's comment on using dev_set_mask()
Changes from v3:
- Fixed Kishon's comment on removing "id" from phy struct and
  removing unneeded "#else" part.
Changes from v2:
- Fixed Sergei's comment on not using address prefix in musb_dsps
  glue and nop transceiver dt dats.
- Also removed the "ti" string in compatible property for nop data.
Changes from v1:
- Defined musb_ida to manage core ids based on Felipe's comment
  in [PATCH 01/11]

Ajay Kumar Gupta (10):
  usb: musb: add musb_ida for multi instance support
  usb: musb: kill global and static for multi instance
  usb: musb: am335x: add support for dual instance
  usb: otg: nop: add support for multiple tranceiver
  usb: musb: dsps: add dt support
  arm/dts: am33xx: Add dt data for usbss
  usb: otg: nop: add dt support
  arm/dts: am33xx: add dt data for usb nop phy
  usb: musb: dsps: remove explicit NOP device creation
  arm/dts: am33xx: add phy phandle to usbss

Ravi Babu (1):
  usb: musb: dsps: get the PHY using phandle api

 .../devicetree/bindings/usb/am33xx-usb.txt |   19 ++
 arch/arm/boot/dts/am33xx.dtsi  |   21 ++
 drivers/usb/musb/am35x.c   |   44 +++--
 drivers/usb/musb/blackfin.c|   28 ++-
 drivers/usb/musb/da8xx.c   |   36 +++-
 drivers/usb/musb/davinci.c |   38 +++--
 drivers/usb/musb/musb_core.c   |   53 --
 drivers/usb/musb/musb_core.h   |6 +
 drivers/usb/musb/musb_debugfs.c|8 +-
 drivers/usb/musb/musb_dsps.c   |  210 +---
 drivers/usb/musb/omap2430.c|   26 ++-
 drivers/usb/musb/tusb6010.c|   30 ++-
 drivers/usb/musb/ux500.c   |   33 +++-
 drivers/usb/otg/nop-usb-xceiv.c|   64 ++-
 include/linux/usb/otg.h|4 +-
 15 files changed, 455 insertions(+), 165 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt

--
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 v7 08/11] arm/dts: am33xx: add dt data for usb nop phy

[Ravi Babu]

From: Ajay Kumar Gupta 

AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 arch/arm/boot/dts/am33xx.dtsi |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 08e9a40..b03a9b5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = "i2c3";
};
 
+   usb0_phy: phy0 {
+   compatible = "nop-xceiv-usb";
+   };
+
+   usb1_phy: phy1 {
+   compatible = "nop-xceiv-usb";
+   };
+
usb_otg_hs: usb_otg_hs {
compatible = "ti,musb-am33xx";
ti,hwmods = "usb_otg_hs";
-- 
1.7.0.4

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

[PATCH v7 10/11] usb: musb: dsps: get the PHY using phandle api

[Ravi Babu]

AM33xx has two PHY of same type used by each musb controller so
use phandle of phy nodes to get the phy pointer.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 .../devicetree/bindings/usb/am33xx-usb.txt |2 ++
 drivers/usb/musb/musb_dsps.c   |5 -
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index 9782585..e2702df 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,6 +12,8 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
  - power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+ - usb0-phy : phandle for usb0 NOP PHY
+ - usb1-phy : phandle for usb1 NOP PHY
 
 NOP USB PHY
  - compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 891c2be..255e71a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -416,9 +416,11 @@ static int dsps_musb_init(struct musb *musb)
 {
struct device *dev = musb->controller;
struct platform_device *pdev = to_platform_device(dev);
+   struct platform_device *parent_pdev = to_platform_device(dev->parent);
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
void __iomem *reg_base = musb->ctrl_base;
+   char name[10];
u32 rev, val;
int status;
 
@@ -426,7 +428,8 @@ static int dsps_musb_init(struct musb *musb)
musb->mregs += wrp->musb_core_offset;
 
/* Get the NOP PHY */
-   musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+   sprintf(name, "usb%d-phy", pdev->id);
+   musb->xceiv = devm_usb_get_phy_by_phandle(&parent_pdev->dev, name);
if (IS_ERR_OR_NULL(musb->xceiv))
return -ENODEV;
 
-- 
1.7.0.4

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

[PATCH v7 05/11] usb: musb: dsps: add dt support

[Ravi Babu]

From: Ajay Kumar Gupta 

Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 .../devicetree/bindings/usb/am33xx-usb.txt |   14 +
 drivers/usb/musb/musb_dsps.c   |   60 +---
 2 files changed, 65 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be "ti,musb-am33xx"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+   represents PERIPHERAL.
+ - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
+   represents PERIPHERAL.
+ - power : Should be "250". This signifies the controller can supply upto
+   500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index c529ccb..13c9341 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +46,10 @@
 
 #include "musb_core.h"
 
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
 /**
  * avoid using musb_readx()/musb_writex() as glue layer should not be
  * dependent on musb core layer symbols.
@@ -496,6 +501,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue 
*glue, u8 id)
struct device *dev = glue->dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data  *pdata = dev->platform_data;
+   struct device_node *np = pdev->dev.of_node;
+   struct musb_hdrc_config *config;
struct platform_device  *musb;
struct resource *res;
struct resource resources[2];
@@ -562,14 +569,40 @@ static int __devinit dsps_create_musb_pdev(struct 
dsps_glue *glue, u8 id)
 
glue->musb[id]  = musb;
 
-   pdata->platform_ops = &dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, "failed to add resources\n");
goto err2;
}
 
+   if (np) {
+   pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(&pdev->dev,
+   "failed to allocate musb platfrom data\n");
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+   if (!config) {
+   dev_err(&pdev->dev,
+   "failed to allocate musb hdrc config\n");
+   goto err2;
+   }
+
+   of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+   of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+   sprintf(res_name, "port%d_mode", id);
+   of_property_read_u32(np, res_name, (u32 *)&pdata->mode);
+   of_property_read_u32(np, "power", (u32 *)&pdata->power);
+   config->multipoint = of_property_read_bool(np, "multipoint");
+
+   pdata->config   = config;
+   }
+
+   pdata->platform_ops = &dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
@@ -601,14 +634,22 @@ static void __devexit dsps_delete_musb_pdev(struct 
dsps_glue *glue, u8 id)
 
 static int __devinit dsps_probe(struct platform_device *pdev)
 {
-   const struct platform_device_id *id = platform_get_device_id(pdev);
-   const struct dsps_musb_wrapper *wrp =
-   (struct dsps_musb_wrapper *)id->driver_data;
+   struct device_node *np = pdev->dev.of_node;
+   const struct of_device_id *match;
+   const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
 
+   match = of_match_node(musb_dsps_of_match, np);
+   if (!match) {
+   dev_err(&pdev->dev, "fail to get matching of_match struct\n");
+   ret = -EINVAL;
+   go

[PATCH v7 11/11] arm/dts: am33xx: add phy phandle to usbss

[Ravi Babu]

From: Ajay Kumar Gupta 

Added NOP PHY phandle to usbss device node as same will be used
to get the phy from otg framework.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 arch/arm/boot/dts/am33xx.dtsi |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b03a9b5..d3ab69a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -172,6 +172,8 @@
port0_mode = <3>;
port1_mode = <1>;
power = <250>;
+   usb0-phy = <&usb0_phy>;
+   usb1-phy = <&usb1_phy>;
};
};
 };
-- 
1.7.0.4

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

[PATCH v7 06/11] arm/dts: am33xx: Add dt data for usbss

[Ravi Babu]

From: Ajay Kumar Gupta 

Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 arch/arm/boot/dts/am33xx.dtsi |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = <0>;
ti,hwmods = "i2c3";
};
+
+   usb_otg_hs: usb_otg_hs {
+   compatible = "ti,musb-am33xx";
+   ti,hwmods = "usb_otg_hs";
+   multipoint = <1>;
+   num_eps = <16>;
+   ram_bits = <12>;
+   port0_mode = <3>;
+   port1_mode = <1>;
+   power = <250>;
+   };
};
 };
-- 
1.7.0.4

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

[PATCH v7 09/11] usb: musb: dsps: remove explicit NOP device creation

[Ravi Babu]

From: Ajay Kumar Gupta 

As NOP device node is now added in am33xx tree so remove the call
which creates the NOP platform_device.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 drivers/usb/musb/musb_dsps.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 13c9341..891c2be 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb->mregs += wrp->musb_core_offset;
 
-   /* Register NOP driver */
-   usb_nop_xceiv_register();
+   /* Get the NOP PHY */
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
return -ENODEV;
-- 
1.7.0.4

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

[PATCH v7 03/11] usb: musb: am335x: add support for dual instance

[Ravi Babu]

From: Ajay Kumar Gupta 

AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.

Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 drivers/usb/musb/musb_dsps.c |  113 +-
 1 files changed, 67 insertions(+), 46 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..7a09d55 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8  poll_seconds;
+   /* number of musb instances */
+   u8  instances;
 };
 
 /**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
  */
 struct dsps_glue {
struct device *dev;
-   struct platform_device *musb;   /* child musb pdev */
+   struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
-   struct timer_list timer;/* otg_workaround timer */
-   u32 __iomem *usb_ctrl;
+   struct timer_list timer[2]; /* otg_workaround timer */
+   unsigned long last_timer[2];/* last timer data for each instance */
+   u32 __iomem *usb_ctrl[2];
u8  usbss_rev;
 };
 
 /**
  * musb_dsps_phy_control - phy on/off
  * @glue: struct dsps_glue *
+ * @id: musb instance
  * @on: flag for phy to be switched on or off
  *
  * This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
  * XXX: This function will be removed once we have a seperate driver for
  * control module
  */
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
 {
u32 usbphycfg;
 
-   usbphycfg = __raw_readl(glue->usb_ctrl);
+   usbphycfg = __raw_readl(glue->usb_ctrl[id]);
 
if (on) {
if (glue->usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue, 
u8 on)
glue->usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
-   __raw_writel(usbphycfg, glue->usb_ctrl);
+   __raw_writel(usbphycfg, glue->usb_ctrl[id]);
 }
 /**
  * dsps_musb_enable - enable interrupts
@@ -207,8 +211,8 @@ static void otg_timer(unsigned long _musb)
struct musb *musb = (void *)_musb;
void __iomem *mregs = musb->mregs;
struct device *dev = musb->controller;
-   struct platform_device *pdev = to_platform_device(dev->parent);
-   struct dsps_glue *glue = platform_get_drvdata(pdev);
+   struct platform_device *pdev = to_platform_device(dev);
+   struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
u8 devctl;
unsigned long flags;
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
 
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE)
-   mod_timer(&glue->timer,
+   mod_timer(&glue->timer[pdev->id],
jiffies + wrp->poll_seconds * HZ);
else
musb->xceiv->state = OTG_STATE_A_IDLE;
@@ -261,9 +265,8 @@ static void otg_timer(unsigned long _musb)
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
 {
struct device *dev = musb->controller;
-   struct platform_device *pdev = to_platform_device(dev->parent);
-   struct dsps_glue *glue = platform_get_drvdata(pdev);
-   static unsigned long last_timer;
+   struct platform_device *pdev = to_platform_device(dev);
+   struct dsps_glue *glue = dev_get_drvdata(dev->parent);
 
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb, 
unsigned long timeout)
musb->xceiv->state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb->controller, "%s active, deleting timer\n",
otg_state_string(musb->xceiv->state));
-   del_timer(&glue->timer);
-   last_timer = jiffies;
+   del_timer(&glue->timer[pdev->id]);
+   glue->last_timer[pdev->id] = jiffies;
return;
}
 
-   if (time_after(last_timer, timeout) && timer_pending(&glue->timer)) {
+   if (time_after(glue->last_timer[pdev->id], timeout) &&
+   timer_pending(&glue->timer[pdev->id])) {
dev_dbg(musb->controller,

[PATCH v7 01/11] usb: musb: add musb_ida for multi instance support

[Ravi Babu]

From: Ajay Kumar Gupta 

Added musb_ida in musb_core.c to manage the multi core ids.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 drivers/usb/musb/am35x.c |   42 --
 drivers/usb/musb/blackfin.c  |   26 --
 drivers/usb/musb/da8xx.c |   34 --
 drivers/usb/musb/davinci.c   |   34 --
 drivers/usb/musb/musb_core.c |   31 +++
 drivers/usb/musb/musb_core.h |2 ++
 drivers/usb/musb/musb_dsps.c |   25 ++---
 drivers/usb/musb/omap2430.c  |   26 --
 drivers/usb/musb/tusb6010.c  |   26 --
 drivers/usb/musb/ux500.c |   33 +++--
 10 files changed, 210 insertions(+), 69 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device 
*pdev)
struct clk  *clk;
 
int ret = -ENOMEM;
+   int musbid;
 
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device 
*pdev)
goto err0;
}
 
-   musb = platform_device_alloc("musb-hdrc", -1);
+   /* get the musb id */
+   musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
+   if (musbid < 0) {
+   dev_err(&pdev->dev, "failed to allocate musb id\n");
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   musb = platform_device_alloc("musb-hdrc", musbid);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
-   goto err1;
+   goto err2;
}
 
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
ret = PTR_ERR(phy_clk);
-   goto err2;
+   goto err3;
}
 
clk = clk_get(&pdev->dev, "ick");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(clk);
-   goto err3;
+   goto err4;
}
 
ret = clk_enable(phy_clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable PHY clock\n");
-   goto err4;
+   goto err5;
}
 
ret = clk_enable(clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
-   goto err5;
+   goto err6;
}
 
+   musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask  = &am35x_dmamask;
musb->dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device 
*pdev)
pdev->num_resources);
if (ret) {
dev_err(&pdev->dev, "failed to add resources\n");
-   goto err6;
+   goto err7;
}
 
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(&pdev->dev, "failed to add platform_data\n");
-   goto err6;
+   goto err7;
}
 
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
-   goto err6;
+   goto err7;
}
 
return 0;
 
-err6:
+err7:
clk_disable(clk);
 
-err5:
+err6:
clk_disable(phy_clk);
 
-err4:
+err5:
clk_put(clk);
 
-err3:
+err4:
clk_put(phy_clk);
 
-err2:
+err3:
platform_device_put(musb);
 
+err2:
+   musb_put_id(&pdev->dev, musbid);
+
 err1:
kfree(glue);
 
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device 
*pdev)
 {
struct am35x_glue   *glue = platform_get_drvdata(pdev);
 
+   musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
clk_disable(glue->clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device 
*pdev)
struct bfin_glue*glue;
 
int ret = -ENOMEM;
+   int musbid;
 
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct platform_device 
*pdev)
goto err0;
}
 
-  

[PATCH v7 07/11] usb: otg: nop: add dt support

[Ravi Babu]

From: Ajay Kumar Gupta 

Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 .../devicetree/bindings/usb/am33xx-usb.txt |3 +++
 drivers/usb/otg/nop-usb-xceiv.c|   10 ++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
  - power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 04ddcee..a66e3bc 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -188,12 +189,21 @@ static int __devexit nop_usb_xceiv_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+   { .compatible = "nop-xceiv-usb" },
+   {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
 static struct platform_driver nop_usb_xceiv_driver = {
.probe  = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name   = "nop_usb_xceiv",
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
 };
 
-- 
1.7.0.4

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

[PATCH v7 04/11] usb: otg: nop: add support for multiple tranceiver

[Ravi Babu]

From: Ajay Kumar Gupta 

Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Ravi Babu 
---
 drivers/usb/musb/am35x.c|2 +-
 drivers/usb/musb/blackfin.c |2 +-
 drivers/usb/musb/da8xx.c|2 +-
 drivers/usb/musb/davinci.c  |4 +-
 drivers/usb/musb/musb_dsps.c|8 +++---
 drivers/usb/musb/tusb6010.c |4 +-
 drivers/usb/otg/nop-usb-xceiv.c |   54 +-
 include/linux/usb/otg.h |4 +-
 8 files changed, 60 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..984e439 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data->set_phy_power(0);
 
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..f1fe728 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb->config->gpio_vrsel);
 
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
return 0;
 }
 
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..a5260b6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
 
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..c7ef654 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
 fail:
usb_put_phy(musb->xceiv);
 unregister:
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
return -ENODEV;
 }
 
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
 
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 7a09d55..c529ccb 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,7 +420,7 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb->mregs += wrp->musb_core_offset;
 
-   /* NOP driver needs change if supporting dual instance */
+   /* Register NOP driver */
usb_nop_xceiv_register();
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
@@ -456,7 +456,7 @@ static int dsps_musb_init(struct musb *musb)
return 0;
 err0:
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
return status;
 }
 
@@ -472,9 +472,9 @@ static int dsps_musb_exit(struct musb *musb)
/* Shutdown the on-chip PHY and its PLL. */
musb_dsps_phy_control(glue, pdev->id, 0);
 
-   /* NOP driver needs change if supporting dual instance */
+   /* Unregister NOP driver */
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 64a0e95..3a12330 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1132,7 +1132,7 @@ done:
iounmap(sync);
 
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
}
return ret;
 }
@@ -1148,7 +1148,7 @@ static int tusb_musb_exit(struct musb *musb)
iounmap(musb->sync_va);
 
usb_put_phy(musb->xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb->xceiv);
return 0;
 }
 
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 803f958..04ddcee 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -31,30 +31,69 @@
 #include 
 #include 
 #include 
+#include 
 
 struct nop_usb_xceiv {
struct usb_phy  phy;
struct device   *dev;
+   struct platform_device  *pd;
 };
 
-static struct platform_device *pd;
+static DEFINE_IDA(nop_ida);
 
-void usb_nop_xceiv_register(void)
+stat

RE: [PATCH] usb: storage: stop all current urbs when device is disconnected

[B, Ravi]

 
Hi Alan

> 
> On Wed, 1 Aug 2012, Ravi Babu wrote:
> 
> > When the scsi mass storage device is disconnected, the current urbs 
> > queued to hcd driver must be cancelled, otherwise the 
> current urbs are 
> > pending at hcd driver and the active urb programmed at host 
> controller 
> > will never be completed. The class driver shall dequeue or 
> cancel all 
> > the urb request submitted to hcd once the device is 
> disconnected and 
> > no longer exits.
> > 
> > Signed-off-by: Ravi Babu 
> > ---
> >  drivers/usb/storage/usb.c |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c 
> > index e23c30a..a313af6 100644
> > --- a/drivers/usb/storage/usb.c
> > +++ b/drivers/usb/storage/usb.c
> > @@ -844,6 +844,8 @@ static void 
> quiesce_and_remove_host(struct us_data *us)
> >  */
> > scsi_lock(host);
> > set_bit(US_FLIDX_DISCONNECTING, &us->dflags);
> > +   /* stop the current urbs when the device got disconnected */
> > +   usb_stor_stop_transport(us);
> 
> This shouldn't be necessary.  This code runs after 
> scsi_remove_host() returns, so there should not be any URBs 
> running at this point.
> 
> Have you actually encountered a problem that this patch fixes?

In specific condition, where the transmit request is in progress and device is 
unplugged from host, found that this current tx request is not 
dequeued/unlinked during disconnect. 

Ravi 
> 
> 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] cdc-ncm: tag Ericsson WWAN devices (eg F5521gw) with FLAG_WWAN

[Peter Meiser]

Hello,

looking at 
http://sourceforge.net/apps/mediawiki/mbm/index.php?title=Main_Page#Supported_devices,
 there are branded Ericsson devices from Dell and Toshiba.

The to-be-added vendor IDs are 0x413c for Dell and 0x0930 for Toshiba.

Please find attached a patch to add these vendor IDs.

Signed-off-by: Peter Meiser 
---

diff -Naur a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1233,6 +1233,26 @@
  .driver_info = (unsigned long) &wwan_info,
},
 
+   /* Dell branded MBM devices like DW5550 */
+   { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+   | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0x413c,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) &wwan_info,
+   },
+
+   /* Toshiba branded MBM devices */
+   { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
+   | USB_DEVICE_ID_MATCH_VENDOR,
+ .idVendor = 0x0930,
+ .bInterfaceClass = USB_CLASS_COMM,
+ .bInterfaceSubClass = USB_CDC_SUBCLASS_NCM,
+ .bInterfaceProtocol = USB_CDC_PROTO_NONE,
+ .driver_info = (unsigned long) &wwan_info,
+   },
+
/* Generic CDC-NCM devices */
{ USB_INTERFACE_INFO(USB_CLASS_COMM,
USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),


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

RE: [PATCH] usb:musb:musb_host: Handle highmem in PIO mode

[Virupax SADASHIVPETIMATH]

> -Original Message-
> From: Virupax SADASHIVPETIMATH
> Sent: Thursday, August 02, 2012 5:35 PM
> To: 'Greg KH'
> Cc: ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; 
> Praveena
> NADAHALLY
> Subject: RE: [PATCH] usb:musb:musb_host: Handle highmem in PIO mode
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, August 02, 2012 4:30 PM
> > To: Virupax SADASHIVPETIMATH
> > Cc: ba...@ti.com; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; 
> > Praveena
> > NADAHALLY
> > Subject: Re: [PATCH] usb:musb:musb_host: Handle highmem in PIO mode
> >
> > On Thu, Aug 02, 2012 at 12:06:42PM +0530, Virupax Sadashivpetimath wrote:
> > > In case of USB bulk transfer, when himem page
> > > is received, the usb_sg_init function sets the
> > > urb transfer buffer to NULL. When such URB
> > > transfer is handled, kernel crashes in PIO mode.
> > > Handle this by mapping the highmem buffer in PIO mode.
> > >
> > > Signed-off-by: Virupax Sadashivpetimath 
> > > 
> >
> > Why is this not a problem in any other host controller?
> 
> Problem is seen only when the RAM on the board is 1GB or more. When the urb 
> sg is in
> highmem.

And also many of the host controllers are using the DMA mode for all sizes
 of urb transfer, because of which the problem is not seen in those 
controllers. 

Thanks 
Virupax S 
 




--
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 ebeam PATCH v2 0/3] new USB eBeam input driver

[Yann Cantin]

Hi,

Second test-drive for a new USB input driver for eBeam
devices.

Following Dmitry's advice, i've remove device specific infrastructure.

Currently, only the Luidia eBeam classic projection model is supported.

Patch 1 and 2 are here to let the ebeam driver be choose to handle
the device instead of the generic-usb hid one (totally useless).

Patch 3 is the actual driver.
Some things to consider :
- I'm not familiar with kernel coding (i've based my work on
  usbtouchscreen.c) so the code certainly contain flaws.
- There's 2 64/64-bits divisions needed, don't know how to handle that the
  right way to be efficient and portable.
- There's 14 custom sysfs files. Yes.

The module run fine with a 3.3.6 and a 3.5.0 kernel.

Thanks for your help.

--
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 ebeam PATCH v2 1/3] hid: hid-ids.h: Add vendor and device ID for eBeam classic device.

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 drivers/hid/hid-ids.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 1dcb76f..b985059 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -271,6 +271,9 @@
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_7349  0x7349
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001  0xa001
 
+#define USB_VENDOR_ID_EFI  0x2650
+#define USB_DEVICE_ID_EFI_CLASSIC  0x1311
+
 #define USB_VENDOR_ID_ELECOM   0x056e
 #define USB_DEVICE_ID_ELECOM_BM084 0x0061
 
-- 
1.7.10

--
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 ebeam PATCH v2 2/3] hid: hid-core.c: Blackist eBeam classic device.

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 drivers/hid/hid-core.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 60ea284..b1ed8ee 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
+#if defined(CONFIG_INPUT_EBEAM_USB)
+   { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) },
+#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, 
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
-- 
1.7.10

--
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 ebeam PATCH v2 3/3] input: misc: New USB eBeam input driver.

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 drivers/input/misc/Kconfig  |   16 +
 drivers/input/misc/Makefile |1 +
 drivers/input/misc/ebeam.c  |  760 +++
 3 files changed, 777 insertions(+)
 create mode 100644 drivers/input/misc/ebeam.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..1e575e4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -83,6 +83,22 @@ config INPUT_BMA150
  To compile this driver as a module, choose M here: the
  module will be called bma150.
 
+config INPUT_EBEAM_USB
+   tristate "USB eBeam driver"
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   help
+ Say Y here if you have a USB eBeam pointing device and want to
+ use it without any proprietary user space tools.
+
+ Have a look at  for
+ a usage description and the required user-space tools.
+
+ Currently, only the Classic Projection model is supported.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ebeam.
+
 config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..2aa9813 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_INPUT_CMA3000_I2C)   += 
cma3000_d0x_i2c.o
 obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
 obj-$(CONFIG_INPUT_DA9052_ONKEY)   += da9052_onkey.o
 obj-$(CONFIG_INPUT_DM355EVM)   += dm355evm_keys.o
+obj-$(CONFIG_INPUT_EBEAM_USB)  += ebeam.o
 obj-$(CONFIG_INPUT_GP2A)   += gp2ap002a00f.o
 obj-$(CONFIG_INPUT_GPIO_TILT_POLLED)   += gpio_tilt_polled.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o
diff --git a/drivers/input/misc/ebeam.c b/drivers/input/misc/ebeam.c
new file mode 100644
index 000..9c698a3
--- /dev/null
+++ b/drivers/input/misc/ebeam.c
@@ -0,0 +1,760 @@
+/**
+ *
+ * eBeam driver
+ *
+ * Copyright (C) 2012 Yann Cantin (yann.can...@laposte.net)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ *  based on
+ *
+ * usbtouchscreen.c by Daniel Ritz 
+ * aiptek.c (sysfs/settings) by Chris Atenasio 
+ *  Bryan W. Headley 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_VERSION "v0.7"
+#define DRIVER_AUTHOR  "Yann Cantin "
+#define DRIVER_DESC"USB eBeam Driver"
+
+/* Common values for eBeam devices */
+#define REPT_SIZE  8   /* packet size*/
+#define MIN_X  0   /* raw coordinates ranges */
+#define MAX_X  0x
+#define MIN_Y  0
+#define MAX_Y  0x
+
+
+#define USB_VENDOR_ID_EFI 0x2650   /* Electronics For Imaging, Inc   */
+#define USB_DEVICE_ID_EFI_CLASSIC  0x1311   /* Classic projection "La banane" 
*/
+
+#define EBEAM_BTN_TIP  0x1  /* tip*/
+#define EBEAM_BTN_LIT  0x2  /* little */
+#define EBEAM_BTN_BIG  0x4  /* big*/
+
+/* ebeam settings */
+struct ebeam_settings {
+   int min_x;
+   int max_x;
+   int min_y;
+   int max_y;
+
+   /* H matrix */
+   s64 h1;
+   s64 h2;
+   s64 h3;
+   s64 h4;
+   s64 h5;
+   s64 h6;
+   s64 h7;
+   s64 h8;
+   s64 h9;
+};
+
+/* ebeam device */
+struct ebeam_device {
+   unsigned char*data;
+   dma_addr_t   data_dma;
+   unsigned char*buffer;
+   int  buf_len;
+   struct urb   *irq;
+   struct usb_interface *interface;
+   struct input_dev *input;
+   char name[128];
+   char phys[64];
+   void *priv;
+
+   struct ebeam_settingscursetting;/* device's current settings */
+   struct ebeam_settingsnewsetting;/* ... and new ones  */
+
+   bool calibrated;/* false : send raw  */
+   /* true  : send computed */
+
+   u16  X, Y;  /* raw coordinates   */
+   int  x, y;  /* computed coordinates  */
+   int  btn_map;   /* internal buttons map  */
+};
+
+
+/* device types */
+enum {
+   DEVTYPE_CLASSIC,
+};
+
+static const struct usb_device_id ebeam_devices[] = {
+   {USB_D

Re: [RFC ebeam PATCH v2 0/3] new USB eBeam input driver

[Jiri Kosina]

On Thu, 2 Aug 2012, Yann Cantin wrote:

> Second test-drive for a new USB input driver for eBeam
> devices.
> 
> Following Dmitry's advice, i've remove device specific infrastructure.
> 
> Currently, only the Luidia eBeam classic projection model is supported.
> 
> Patch 1 and 2 are here to let the ebeam driver be choose to handle
> the device instead of the generic-usb hid one (totally useless).

Just merge 1 and 2 together, not necessary to have two commits because of 
that.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: gadgetfs w/ multithreading and blocking I/O fails USB-IF Ch9 Halt Endpoint Test

[Alan Stern]

On Wed, 1 Aug 2012, Dan Rittersdorf wrote:

> Hello,
> 
> I am working on a user-level USB peripheral device driver with a single 
> pair of bulk in/out endpoints.  It uses the gadgetfs() driver.
> 
> I am initially running the usb.c example test program on gadgetfs, using 
> the Windows USB 2.0 Command Verifier from usb.org.
> My target is a CM-T3730 board from compulab running a 3.0.32 kernel and 
> a TimeSys root file system.  It uses the musb-hdrc controller.
> 
> When the USB20CV application attempts to execute the "Halt Endpoint 
> Test", it tries to select interface 0, and a SET_INTERFACE request 
> results in
> a call to ioctl ( ... GADGET_CLEAR_HALT) on the bulk endpoints. The 
> ep_ioctl() function in drivers/usb/gadget/inode.c is called from the ep0 
> thread,
> which in turn calls get_ready_ep(), and ultimately, 
> mutex_lock_interruptible(&epdata->lock);
> 
> But the endpoint is managed by another thread which is blocked in 
> ep_read() with the same endpoint mutex locked.This results in a 
> deadlock, and the remainder of the Chapter 9 tests are failed.

It looks like the lesson is not to have one thread accessing an 
endpoint at the same time as another thread issues a CLEAR_HALT.

> (The test fares slightly better with async  enabled, but still fails on 
> the unimplemented ep3 interrupt endpoint.)
> 
> My driver's endpoint monitor threads suffer the same fate, as I do not 
> currently use async I/O.  The halt endpoint test is my only failure, 
> though.
> 
> I don't find any discussion of this problem on the archives -- is anyone 
> aware of the issue?   Is there a solution other than using async I/O?
> Can anyone suggest a potential solution for multiple threads with 
> blocking I/O?

You can always interrupt the ep_read thread by sending it a signal.  
Then have it wait until the CLEAR_HALT is complete.

There are some known problems related to locking in gadgetfs (it 
submits requests while holding a lock that the completion routine will 
take).  So far nobody has cared about it enough to do a careful audit 
and fix.

> How is the maturity of the Function File System composite gadget driver 
> in comparison?   Would it be better to convert to async I/O with gadgetfs,
> or to make the move to Function File System?

I don't know.

> Thank you in advance for your consideration.

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: ehci-platform: add pm_runtime_xx()

[Alan Stern]

On Wed, 1 Aug 2012 kuninori.morimoto...@renesas.com wrote:

> It is possible to power-on on platform setup level
> if Rafael and Magnus don't care this style.
> Then, I don't need this patch on ehci/ohci driver.
>   
>   1) power-on on platform setup timing
>   2) use ehci/ohci driver
> 
> the other is that add .power callback on usb_ehci_pdata,
> and control all power on this.
> 
> -- probe --
>if (pdata->power)
>   pdata->power(xxx, 1)
> 
>usb_add_hcd()
> 
>-- remove --
>usb_remove_hcd()
> 
>if (pdata->power)
>   pdata->power(xxx, 0)

That's a great idea.  Would you like to write a patch to do it?  
Remember, you'll have to modify ehci_platform_suspend() and 
ehci_platform_resume() as well.

All changes should be based on the current linux-next tree.  The EHCI
suspend/resume code is significantly different from the code in 3.5.

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: ehci-platform: add pm_runtime_xx()

[Alan Stern]

On Thu, 2 Aug 2012, Magnus Damm wrote:

> From my point of view this all depends on what the hardware supports.
> If the USB host controller hardware can be powered down (power domain
> off, clock off) when no USB hardware is connected, but still perform
> hotplug detection of a newly added device, then if so then I'd like to
> see more fine grained PM support in the drivers. If that's not
> possible then I believe the more static approach (on probe/remove) is
> fine. Perhaps the latter is a good first step.

The two techniques are independent, and it's easy to implement either
one without the other.  Hence we might as well allow for both
approaches.

Alan Stern

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

Re: [PATCH 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

[Alan Stern]

On Thu, 2 Aug 2012, Lan Tianyu wrote:

> > How about if we start with only the first policy rule: Ports that can
> > never have anything plugged in should be shut down automatically.
> So we should add a variable for each port to record whether the port
> has been ever attached with devices. When set sys file set to "auto"
> these port should power off directly, right?

That's not what I meant.  There's no reason to keep track of whether
the port has ever been attached to a device.  The only ports we should 
power down (at least for now) are ports where it's _impossible_ to 
attach a device.

Alan STern

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

Re: [PATCH 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

[Alan Stern]

On Thu, 2 Aug 2012, Lan Tianyu wrote:

> A summary about what we should do now after such long discussion. If I 
> lost something or miss something, please correct me.
> 
> 1) Add "auto" option to each port's power policy sysfs attribute. When
> set to "auto", those ports which have never been attached with devices
> will be power off immediately.

No.  Ports will be powered down only if it's impossible to attach a 
device, that is, if PortIsConnectable is clear.  As a safety check, you 
should also verify that no device is currently attached.

> 2)Expose the ACPI PortIsConnectable, UserVisible (If it was on the ACPI 
> platfrom) and usb DeviceRemovable flag via sysfs attributes.
> 
> 3)Root-hub set port's DeviceRemovable flag where PortIsConnectable and 
> UserVisible are clear.

Set DeviceRemovable whenever UserVisible is set.  Right now ehci-hcd 
and uhci-hcd always set DeviceRemovable to 0.

> 4)Add QUIRK_POWEROFF_MORPHS flags for those devices which retain
> important settings across a reset but lose them when power is removed.

This flag doesn't care about resets.  It applies to any device which 
loses important settings when bus power is removed.

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:musb:musb_host: Handle highmem in PIO mode

[Alan Stern]

On Thu, 2 Aug 2012, Virupax Sadashivpetimath wrote:

> In case of USB bulk transfer, when himem page
> is received, the usb_sg_init function sets the
> urb transfer buffer to NULL. When such URB
> transfer is handled, kernel crashes in PIO mode.
> Handle this by mapping the highmem buffer in PIO mode.


> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -21,6 +21,7 @@
>  #include  /* for current && schedule_timeout */
>  #include  /* for struct mutex */
>  #include /* for runtime PM */
> +#include 
>  
>  struct usb_device;
>  struct usb_driver;
> @@ -1309,6 +1310,7 @@ struct urb {
>   usb_complete_t complete;/* (in) completion routine */
>   struct usb_iso_packet_descriptor iso_frame_desc[0];
>   /* (in) ISO ONLY */
> + struct sg_mapping_iter sg_miter; /* handling highmem data in PIO mode */
>  };

This is unacceptable.  Fields like this should be stored in the 
URB's hcpriv structure, not in the URB itself.

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: storage: stop all current urbs when device is disconnected

[Alan Stern]

On Thu, 2 Aug 2012, B, Ravi wrote:

> > > --- a/drivers/usb/storage/usb.c
> > > +++ b/drivers/usb/storage/usb.c
> > > @@ -844,6 +844,8 @@ static void 
> > quiesce_and_remove_host(struct us_data *us)
> > >*/
> > >   scsi_lock(host);
> > >   set_bit(US_FLIDX_DISCONNECTING, &us->dflags);
> > > + /* stop the current urbs when the device got disconnected */
> > > + usb_stor_stop_transport(us);
> > 
> > This shouldn't be necessary.  This code runs after 
> > scsi_remove_host() returns, so there should not be any URBs 
> > running at this point.
> > 
> > Have you actually encountered a problem that this patch fixes?
> 
> In specific condition, where the transmit request is in progress and
> device is unplugged from host, found that this current tx request is
> not dequeued/unlinked during disconnect.

Please provide more information.  What specific condition?  What was 
the current request?  How did this happen?

If the device was unplugged while an URB was active, the URB should
have completed very quickly with a failure.  Why didn't it fail?

As far as I can tell, this shouldn't be needed.  scsi_remove_host() 
calls scsi_forget_host(), which calls __scsi_remove_device(), which 
calls scsi_free_queue(), which calls blk_cleanup_queue(), which calls 
blk_drain_queue(), which should wait until all pending requests are 
finished.

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: [alsa-devel] Alsa: USB Class 2 Audio soundcard device disappears suddenly

[Joao Bonina]

- Original Message -
> From: Joao Bonina 
> To: Alan Stern 
> Cc: "alsa-de...@alsa-project.org" ; linux-usb 
> ; Daniel Mack 
> Sent: Wednesday, 1 August 2012, 11:07
> Subject: Re: [alsa-devel] Alsa: USB Class 2 Audio soundcard device disappears 
> suddenly
> 
> 
> 
>> 
>>  From: Alan Stern 
>> To: Joao Bonina  
>> Cc: Daniel Mack ; 
> "alsa-de...@alsa-project.org" ; 
> linux-usb  
>> Sent: Tuesday, 31 July 2012, 15:35
>> Subject: Re: [alsa-devel] Alsa: USB Class 2 Audio soundcard device 
> disappears suddenly
>> 
>> On Tue, 31 Jul 2012, Joao Bonina wrote:
>> 
>>>  You're right about the EMI message, it's happening when the 
> streaming stops.
>>> 
>>>  I've tried different cables before, but that didn't solve the 
> problem.
>>> 
>>>  The motherboard is an Alix 1D, and I'm using the onboard USB 2.0 
> ports.
>>> 
>>>  If this really is an EMI issue, guess I'll have to source some kind 
> of miniPCI-USB 2.0 card and see if that solves the problem.
>> 
>> Another possibility is to put a USB hub before the sound device.  That 
>> _might_ clean up the signal.
>> 
>> Alan Stern
>> 
> 
> 
> Thanks for that suggestion, Alan.
> 
> I  used a cheap hub that I had stashed away. At the begining that seemed to 
> solve the problem. But after a while, some clicks and pops became audible.
> 
> Disconnected it all for a while, and when I reconnected, the problem was back 
> again with this message on mpd.log:
> 
> Aug 01 05:57 : output: "USB" [alsa] failed to play: No such device
> Aug 01 05:57 : output: closed plugin=alsa name="USB"
> 
> 
> 
> This time, there's no EMI message in dmesg. 
> 
> 
> Still have to try copying files from one usb flash to another.
> 
> João Bonina
> 
> 

Did the copying test and all went well there.

Also did a usbmon 
session with the DAC disconnecting/reconnecting automatically. There was
 no EMI message in dmesg there, and I'm connecting the DAC through a USB
 hub.

Analyzed the usbmon log with Virtual USB analyzer, but 
couldn't find reasons there for the disconnection. I'm not very 
experienced in this subject, so excuse me if I'm missing something 
obvious here.

I have the usbmon log. If someone wants to take a look at it, please let me 
know and I'll send it.


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

Re: [PATCH 2/3] usb: Take attribute avoid_reset_quirk out of usb device's attribute group

[Alan Stern]

On Thu, 2 Aug 2012, Lan Tianyu wrote:

> >> 3)Root-hub set port's DeviceRemovable flag where PortIsConnectable and
> >> UserVisible are clear.
> >
> > Set DeviceRemovable whenever UserVisible is set.  Right now ehci-hcd
> > and uhci-hcd always set DeviceRemovable to 0.
> 
> UserVisible is got from ACPI and permanent. So we only need set once when
> the port binding with acpi.

However DeviceRemovable is filled in dynamically, whenever the
Get-Hub-Descriptor request is received by a host controller driver.

> >> 4)Add QUIRK_POWEROFF_MORPHS flags for those devices which retain
> >> important settings across a reset but lose them when power is removed.
> >
> > This flag doesn't care about resets.  It applies to any device which
> > loses important settings when bus power is removed.
> >
> Since it applies to any devices, how about renaming QUIRK_POWEROFF?
> not all device morphs.

Okay, you could name it that.  And you could change QUIRK_RESET_MORPHS 
to QUIRK_RESET.  Unless Oliver objects.  :-)

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: [alsa-devel] Alsa: USB Class 2 Audio soundcard device disappears suddenly

[Alan Stern]

On Thu, 2 Aug 2012, Joao Bonina wrote:

> Did the copying test and all went well there.
> 
> Also did a usbmon session with the DAC disconnecting/reconnecting 
> automatically. There was no EMI message in dmesg there, and I'm 
> connecting the DAC through a USB hub.
> 
> Analyzed the usbmon log with Virtual USB analyzer, but couldn't find
> reasons there for the disconnection. I'm not very experienced in this
> subject, so excuse me if I'm missing something obvious here.
> 
> I'm attaching the usbmon log if someone wants to take a look at it.
> Sorry for the long attachment file.

I agree, there's no obvious reason for the disconnection in the log.  
Possible explanations include a bad cable connection or a bug in the 
sound card's firmware.

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: storage: stop all current urbs when device is disconnected

[B, Ravi]

Hi 

> On Thu, 2 Aug 2012, B, Ravi wrote:
> 
> > > > --- a/drivers/usb/storage/usb.c
> > > > +++ b/drivers/usb/storage/usb.c
> > > > @@ -844,6 +844,8 @@ static void
> > > quiesce_and_remove_host(struct us_data *us)
> > > >  */
> > > > scsi_lock(host);
> > > > set_bit(US_FLIDX_DISCONNECTING, &us->dflags);
> > > > +   /* stop the current urbs when the device got 
> disconnected */
> > > > +   usb_stor_stop_transport(us);
> > > 
> > > This shouldn't be necessary.  This code runs after
> > > scsi_remove_host() returns, so there should not be any 
> URBs running 
> > > at this point.
> > > 
> > > Have you actually encountered a problem that this patch fixes?
> > 
> > In specific condition, where the transmit request is in 
> progress and 
> > device is unplugged from host, found that this current tx 
> request is 
> > not dequeued/unlinked during disconnect.
> 
> Please provide more information.  What specific condition?  
> What was the current request?  How did this happen?
> 
> If the device was unplugged while an URB was active, the URB 
> should have completed very quickly with a failure.  Why 
> didn't it fail?
> 
> As far as I can tell, this shouldn't be needed.  
> scsi_remove_host() calls scsi_forget_host(), which calls 
> __scsi_remove_device(), which calls scsi_free_queue(), which 
> calls blk_cleanup_queue(), which calls blk_drain_queue(), 
> which should wait until all pending requests are finished.
>

Alan you may be correct. 
Let me explain, the issue occurs while unplugging the device during Tx 
transfer, 
1) During Tx transfer, TX-DMA is programmed to transfer the data. 
2) The TX-DMA completes the transfer and generates completion interrupt. 
3) On tx completion interrupt context the URB is given back. 
In normal scenario, the sequence 1 to 3 occurs during tx transfers.
Issue occurs when the device is unplugged while TX-DMA transfer is in progress. 
The DMA halts and never generates completion interrupt. In this scenario, this 
active request at DMA is given back when application calls dequeue or unlink 
the URB. Since in this scenario since there is no timeout occurs on the URB, we 
expect the scsi layer should unlink the active URB upon DISCONNECT of device. 

In this scenario, when the DISCONNECT occur, scsi does not unlink the active 
URB, this patch fixing this issue. 
Can you point me which function unlink the active URB (which is not returned). 
Let me know if you have better solution or any suggestion.

Thanks
Ravi B

> 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: storage: stop all current urbs when device is disconnected

[Alan Stern]

On Thu, 2 Aug 2012, B, Ravi wrote:

> Alan you may be correct.  Let me explain, the issue occurs while
> unplugging the device during Tx transfer,
> 1) During Tx transfer, TX-DMA is programmed to transfer the data. 
> 2) The TX-DMA completes the transfer and generates completion interrupt. 
> 3) On tx completion interrupt context the URB is given back. 
> In normal scenario, the sequence 1 to 3 occurs during tx transfers.
> Issue occurs when the device is unplugged while TX-DMA transfer is in
> progress. The DMA halts and never generates completion interrupt. In

What host controller driver are you using?

Why doesn't the controller hardware detect that the device fails to
send handshake packets and abort the transfer?  According to the USB-2
spec, after three failures the controller must end the transfer.  This
sounds like a bug in the controller or its driver.

> this scenario, this active request at DMA is given back when
> application calls dequeue or unlink the URB. Since in this scenario
> since there is no timeout occurs on the URB, we expect the scsi layer
> should unlink the active URB upon DISCONNECT of device.

Not until the command times out.

> In this scenario, when the DISCONNECT occur, scsi does not unlink the
> active URB, this patch fixing this issue.
> Can you point me which function unlink the active URB (which is not
> returned).
> Let me know if you have better solution or any suggestion.

I would expect the command to time out and be unlinked by
command_abort() after 30 seconds or so, and I would expect
scsi_remove_host() to wait until this happens.  If this doesn't happen,
it indicates a bug in the SCSI or block layers.

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: gadgetfs w/ multithreading and blocking I/O fails USB-IF Ch9 Halt Endpoint Test

[Alan Stern]

On Thu, 2 Aug 2012, Dan Rittersdorf wrote:

> > It looks like the lesson is not to have one thread accessing an
> > endpoint at the same time as another thread issues a CLEAR_HALT.
> 
> Thank you -- that spawned a couple thoughts on a potential solution.
> 
> And I appreciate you refraining from simply saying "doh!"   :-)
> I should have seen the problem as an application level issue, but was 
> blind to it because I presumed that "usb.c" was known to "work".

If you have any bug fixes for usb.c, please send them in.

> > There are some known problems related to locking in gadgetfs (it 
> > submits requests while holding a lock that the completion routine will 
> > take). So far nobody has cared about it enough to do a careful audit 
> > and fix. 
> 
> Yes, I ran into that issue quickly on this project.   I addressed one 
> case in ep0_read() by unlocking around the usb_ep_queue() call.
> I have not yet discovered any other instances.  ep0_write() doesn't make 
> the same mistake.

I have had this patch hanging around for a long time.  I don't know if 
it's entirely right (I don't use gadgetfs much), but see what you 
think.

Alan Stern



Index: usb-3.3/drivers/usb/gadget/inode.c
===
--- usb-3.3.orig/drivers/usb/gadget/inode.c
+++ usb-3.3/drivers/usb/gadget/inode.c
@@ -998,8 +998,11 @@ ep0_read (struct file *fd, char __user *
struct usb_ep   *ep = dev->gadget->ep0;
struct usb_request  *req = dev->req;
 
-   if ((retval = setup_req (ep, req, 0)) == 0)
+   if ((retval = setup_req (ep, req, 0)) == 0) {
+   spin_unlock(&dev->lock);
retval = usb_ep_queue (ep, req, GFP_ATOMIC);
+   spin_lock(&dev->lock);
+   }
dev->state = STATE_DEV_CONNECTED;
 
/* assume that was SET_CONFIGURATION */
@@ -1533,8 +1536,10 @@ delegate:
w_length);
if (value < 0)
break;
+   spin_unlock(&dev->lock);
value = usb_ep_queue (gadget->ep0, dev->req,
GFP_ATOMIC);
+   spin_lock(&dev->lock);
if (value < 0) {
clean_req (gadget->ep0, dev->req);
break;
@@ -1557,7 +1562,9 @@ delegate:
if (value >= 0 && dev->state != STATE_DEV_SETUP) {
req->length = value;
req->zero = value < w_length;
+   spin_unlock(&dev->lock);
value = usb_ep_queue (gadget->ep0, req, GFP_ATOMIC);
+   spin_lock(&dev->lock);
if (value < 0) {
DBG (dev, "ep_queue --> %d\n", value);
req->status = 0;

--
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: new device for qmi_wwan and option Vodafone/ZTE K5006Z

[Marcel Holtmann]

Hi Thomas,

> The network connection is working via wwan1 , at least with IPv4.
> The LTE speed here with 8-16Mbit/s is limited by my contract, not the device.
> 
> At the moment I have problems with IPv6, but I think this is not a problem of 
> the device, more a problem of my apn, which may be only accessible via 3G.

if you are on Vodafone Germany LTE, then yes, it only gives you IPv4 for
some weird reason.

Regards

Marcel


--
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: stop all current urbs when device is disconnected

[Alan Stern]

On Thu, 2 Aug 2012, Alan Stern wrote:

> On Thu, 2 Aug 2012, B, Ravi wrote:
> 
> > Alan you may be correct.  Let me explain, the issue occurs while
> > unplugging the device during Tx transfer,
> > 1) During Tx transfer, TX-DMA is programmed to transfer the data. 
> > 2) The TX-DMA completes the transfer and generates completion interrupt. 
> > 3) On tx completion interrupt context the URB is given back. 
> > In normal scenario, the sequence 1 to 3 occurs during tx transfers.
> > Issue occurs when the device is unplugged while TX-DMA transfer is in
> > progress. The DMA halts and never generates completion interrupt. In
> 
> What host controller driver are you using?
> 
> Why doesn't the controller hardware detect that the device fails to
> send handshake packets and abort the transfer?  According to the USB-2
> spec, after three failures the controller must end the transfer.  This
> sounds like a bug in the controller or its driver.
> 
> > this scenario, this active request at DMA is given back when
> > application calls dequeue or unlink the URB. Since in this scenario
> > since there is no timeout occurs on the URB, we expect the scsi layer
> > should unlink the active URB upon DISCONNECT of device.
> 
> Not until the command times out.
> 
> > In this scenario, when the DISCONNECT occur, scsi does not unlink the
> > active URB, this patch fixing this issue.
> > Can you point me which function unlink the active URB (which is not
> > returned).
> > Let me know if you have better solution or any suggestion.
> 
> I would expect the command to time out and be unlinked by
> command_abort() after 30 seconds or so, and I would expect
> scsi_remove_host() to wait until this happens.  If this doesn't happen,
> it indicates a bug in the SCSI or block layers.

I tried doing a similar experiment on my system.  I got rid of the code
that makes ehci-hcd stop retrying after a maximum number of transaction
errors (so that it would continue to retry indefinitely), and then
pulled out my USB flash drive while a program was reading from it.

The result was exactly as predicted: After 30 seconds the current 
transfer was aborted, and scsi_remove_host() waited for this to happen.

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: new device for qmi_wwan and option Vodafone/ZTE K5006Z

[Thomas Schäfer]

Am Donnerstag, 2. August 2012, 21:25:49 schrieben Sie:
> Hi Thomas,
> 

> > At the moment I have problems with IPv6, but I think this is not a
> > problem of the device, more a problem of my apn, which may be only
> > accessible via 3G.
> 
> if you are on Vodafone Germany LTE, then yes, it only gives you IPv4 for
> some weird reason.

I have a normal contract with t-mobile germany (ipv4 only, and nothing more, 
every question regarding IPv6 fails because of incompetent staff)
IPv4 works with 2G/3G/4G, but in 4G I forced to RFC-1918-addresses.
In 2G/3G I have had the permission to use an APN with public IPs.

Additionally I have got one Test-SIM from Vodafone Germany for IPv6-test-
purposes. 

The new devices are also new for me, the tools are not fully developed  yet. 
So I have some problems, e.g. selection of a specified network. For one 
device/operator  I found the AT-command, but on the other device it does not 
work, or has to be done via qmi or whatever. 

I finish here. It starts to be off-topic.

I hope someone adds the ID 19d2:1018 with the right subdevices to the option 
and qmi_wwan modules, and removes the oops. 

After that testing will be easier.

Regards,
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

Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Alan Stern]

On Wed, 1 Aug 2012, Rafael J. Wysocki wrote:

> What I really thought about was to do _get_noresume(), then check if the
> device is active and if not, queue up a work item (or another delayed
> execution in process context) that will do pm_runtime_resume() and
> then access the hardware.
> 
> Why do I think it's better than plain pm_runtime_get()?  Because the code
> path calling pm_runtime_resume() will know that it is safe to access the
> hardware after it has returned (unless it returns an error code, but
> that's exceptional).
> 
> In contrast, with pm_runtime_get() there is no way to predict when the
> device is going to be resumed, so if the device happens to be suspended
> when pm_runtime_get() returns, the driver kind of has to poll it until
> it becomes active, or use a wait queue woken up from the resume callback,
> or do all of the processing in the resume callback itself (like in the
> example you mentioned).  I'm not sure if the expectation that all driver
> writers will be able to implement any of these options correctly is a 
> realistic
> one.

I don't know about that -- the logic involved in doing the processing 
within the resume callback isn't terribly complicated.  At least, not 
much more complicated than the logic involved in setting up a custom 
work routine as you suggest.

Anyway with the existing code, driver writers are free to choose 
whichever approach they prefer.

> > Check out the sample driver code in section 9 of 
> > Documentation/power/runtime_pm.txt, especially the foo_read_or_write() 
> > routine.
> 
> Well, that shouldn't need the is_suspended flag at all, methinks, and the
> reason it does need it is because it uses pm_runtime_get().

Not so.  Consider your scheme.  When starting an I/O request, you call
pm_runtime_get_noresume() and then check to see if the device is
active, say by calling pm_runtime_suspended().  Suppose at that moment
the suspend callback has just finished and has released the private
spinlock.  The device's status is still RPM_SUSPENDING, so
pm_runtime_suspended() returns 0 and you try to carry out the I/O.

To fix this problem you have to synchronize the status checking with
the suspend/resume operations.  This means the status changes have to
occur under the protection of the private lock, which means a private
flag is needed.

>  Moreover,
> processing requests in the resume callback is not something I'd recommend
> to anyone, because that's going to happen when the status of the device
> is RPM_RESUMING, we're holding a reference on the parent (if there's one) etc.

I don't see any problem with that.  The parent's child_count will be 
incremented while the requests are being processed regardless.  And if 
you've been waiting for the device to resume in order to carry out some 
processing, within the resume callback is the logical place to do the 
work.  It avoids the overhead of a second context switch.

> So, it looks like I don't really agree with the example. :-)

Feel free to add your scheme as a second example in the document.  :-)
But please don't remove the first example, unless you can find 
something actually wrong with it.

> > While you're changing names around, consider also adding a "_runtime"  
> > somewhere to:
> > 
> > pm_children_suspended,
> > pm_schedule_suspend,
> > pm_request_idle,
> > pm_request_resume,
> > pm_request_autosuspend.
> > 
> > For example, we could have pm_runtime_idle_async instead of 
> > pm_request_idle.
> 
> Well, these are not as misleading as pm_runtime_get(), at least in principle.

No, but it would be good to be more consistent about our naming.  
Making sure all the function names contain "_runtime" would help.

I suppose we could keep pm_runtime_get_sync as is, and just change
pm_runtime_get to pm_runtime_get_async (and likewise for _put).  That
could reduce the confusion during the changeover.

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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Rafael J. Wysocki]

On Thursday, August 02, 2012, Alan Stern wrote:
> On Wed, 1 Aug 2012, Rafael J. Wysocki wrote:
> 
> > What I really thought about was to do _get_noresume(), then check if the
> > device is active and if not, queue up a work item (or another delayed
> > execution in process context) that will do pm_runtime_resume() and
> > then access the hardware.
> > 
> > Why do I think it's better than plain pm_runtime_get()?  Because the code
> > path calling pm_runtime_resume() will know that it is safe to access the
> > hardware after it has returned (unless it returns an error code, but
> > that's exceptional).
> > 
> > In contrast, with pm_runtime_get() there is no way to predict when the
> > device is going to be resumed, so if the device happens to be suspended
> > when pm_runtime_get() returns, the driver kind of has to poll it until
> > it becomes active, or use a wait queue woken up from the resume callback,
> > or do all of the processing in the resume callback itself (like in the
> > example you mentioned).  I'm not sure if the expectation that all driver
> > writers will be able to implement any of these options correctly is a 
> > realistic
> > one.
> 
> I don't know about that -- the logic involved in doing the processing 
> within the resume callback isn't terribly complicated.  At least, not 
> much more complicated than the logic involved in setting up a custom 
> work routine as you suggest.

That's why I had the idea of pm_request_resume_and_call(dev, func)
described in this message:

http://marc.info/?l=linux-usb&m=134377126804170&w=4

although perheps it would be better to call it something like
pm_runtime_async_resume_and_call(dev, func).

> Anyway with the existing code, driver writers are free to choose 
> whichever approach they prefer.

I wonder how many instances of pm_runtime_get() used in a wrong way there
are in the kernel right now.  I guess I'll sacrifice some time to check
that.

> > > Check out the sample driver code in section 9 of 
> > > Documentation/power/runtime_pm.txt, especially the foo_read_or_write() 
> > > routine.
> > 
> > Well, that shouldn't need the is_suspended flag at all, methinks, and the
> > reason it does need it is because it uses pm_runtime_get().
> 
> Not so.  Consider your scheme.  When starting an I/O request, you call
> pm_runtime_get_noresume() and then check to see if the device is
> active, say by calling pm_runtime_suspended().  Suppose at that moment
> the suspend callback has just finished and has released the private
> spinlock.  The device's status is still RPM_SUSPENDING, so
> pm_runtime_suspended() returns 0 and you try to carry out the I/O.
> 
> To fix this problem you have to synchronize the status checking with
> the suspend/resume operations.  This means the status changes have to
> occur under the protection of the private lock, which means a private
> flag is needed.

What about checking if the status is RPM_ACTIVE under dev->power.lock?
That's what rpm_resume() does, more or less.

> >  Moreover,
> > processing requests in the resume callback is not something I'd recommend
> > to anyone, because that's going to happen when the status of the device
> > is RPM_RESUMING, we're holding a reference on the parent (if there's one) 
> > etc.
> 
> I don't see any problem with that.  The parent's child_count will be 
> incremented while the requests are being processed regardless.  And if 
> you've been waiting for the device to resume in order to carry out some 
> processing, within the resume callback is the logical place to do the 
> work.

Unless your _driver_ callback is actually executed from within a PM domain
callback, for example, and something else may be waiting for it to complete,
so your data processing is adding latencies to some other threads.  I'm not
making that up, by the way, that really can happen.

And what if you are a parent waited for by a child to resume so that _it_
can process its data?  Would you still want to process your data in the
resume callback in that case?

> It avoids the overhead of a second context switch.

That may be avoided without processing data from within the resume callback,
although not with the current code.

> > So, it looks like I don't really agree with the example. :-)
> 
> Feel free to add your scheme as a second example in the document.  :-)
> But please don't remove the first example, unless you can find 
> something actually wrong with it.

Well, it should work in general, so it is not functionally wrong.  However,
I wouldn't like to regard it as the best thing we can offer. :-)

> > > While you're changing names around, consider also adding a "_runtime"  
> > > somewhere to:
> > > 
> > >   pm_children_suspended,
> > >   pm_schedule_suspend,
> > >   pm_request_idle,
> > >   pm_request_resume,
> > >   pm_request_autosuspend.
> > > 
> > > For example, we could have pm_runtime_idle_async instead of 
> > > pm_request_idle.
> > 
> > Well, these are not as misleading as pm_runtime_get(), at least in 
> >

Re: [PATCH v7 00/11] usb: musb: adding multi instance support

[Daniel Mack]

Hi Ravi,

On 02.08.2012 14:12, Ravi Babu wrote:
> This series of patches adds,
> a) Multi instances support in musb driver
> b) DT support for musb_dsps glue layer
> c) DT support for NOP transceiver
> 
> AM33xx and TI81xx has dual musb controller and has two usb PHY of same type.
> This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to
> get the PHY of same type. This API support is being added by Kishon's patch
> discussed at [1]
> 
> The series applies to linux-omap (master branch)
>   + Vaibhav baseport patches on his tree at [3]
>   + Kishon's multi phy patches on Felipe's branch 'xceiv'
>   + Kishon's patch on phandle at [1]
>   + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7]
>   + Damodar's recent patch at [2] 
> 
> and have been tested on Beaglebone board.

I would like to test these patches on a custom AM33xx board, but I'm
having trouble applying them. I am based on Linus' master tree, and "git
am" fails for drivers/usb/musb/musb_dsps.c. The commits I got for that
file are:

ded017ee6 usb: phy: fix return value check of usb_get_phy
662dca54c usb: otg: support for multiple transceivers by a single controller
721002ec1 usb: otg: utils: rename function name in OTG utils
9ecb88752 usb: musb: Add support for ti81xx platform

I wonder which branch you are based on and which tree those patches
should go thru eventually.


Thanks,
Daniel

--
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: FW: [PATCH] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware

[Alexis R. Cortes]

Hi Sarah,

I have rewritten my code following your recommendations. Could you please 
review it and give your comments? If everything is fine I'll proceed to 
generate the patch and submit it.

The description of my patch is:
---
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware

This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.

If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.

As a result of this, the port will seem "dead" to the user and no 
device connections or disconnections will be detected.

For solving this, the patch creates a timer which polls every 2 
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected. 

Since the issue is being caused by a piece of hardware, the timer 
will be enabled ONLY on those systems that have the SN65LVPE502CP 
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).

This patch applies for these systems: 
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
---

The 'git diff' of my change is as follows:

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 7b01094..3a3c614 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -493,11 +493,47 @@ static void xhci_hub_report_link_state(u32 *status, u32 
status_reg)
 * when this bit is set.
 */
pls |= USB_PORT_STAT_CONNECTION;
+   } else {
+   /*
+* If CAS bit isn't set but the Port is already at
+* Compliance Mode, fake a connection so the USB core
+* notices the Compliance state and resets the port.
+* This resolves an issue generated by the SN65LVPE502CP
+* in which sometimes the port enters compliance mode
+* caused by a delay on the host-device negotiation.
+*/
+   if (pls == USB_SS_PORT_LS_COMP_MOD)
+   pls |= USB_PORT_STAT_CONNECTION;
}
+
/* update status field */
*status |= pls;
 }
 
+/* Function for Compliance Mode Quirk.
+ *
+ * This Function verifies if all xhc USB3 ports have entered U0, if so,
+ * the compliance mode timer is deleted. A port won't enter
+ * compliance mode if it has previously entered U0.
+ */
+void xhci_del_comp_mod_timer(struct xhci_hcd *xhci, u32 status, u16 wIndex)
+{
+   u32 all_ports_seen_u0 = ((1 << xhci->num_usb3_ports)-1);
+   bool port_in_u0 = ((status & PORT_PLS_MASK) == XDEV_U0);
+
+   if (!(xhci->quirks & XHCI_COMP_MODE_QUIRK))
+   return;
+
+   if ((xhci->port_status_u0 != all_ports_seen_u0) && port_in_u0) {
+   xhci->port_status_u0 |= 1 << wIndex;
+   if (xhci->port_status_u0 == all_ports_seen_u0) {
+   del_timer_sync(&xhci->comp_mode_recovery_timer);
+   xhci_dbg(xhci, "All USB3 ports have entered U0 
already!\n");
+   xhci_dbg(xhci, "Compliance Mode Recovery Timer 
Deleted.\n");
+   }
+   }
+}
+
 int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
u16 wIndex, char *buf, u16 wLength)
 {
@@ -645,6 +681,11 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
/* Update Port Link State for super speed ports*/
if (hcd->speed == HCD_USB3) {
xhci_hub_report_link_state(&status, temp);
+   /*
+* Verify if all USB3 Ports Have entered U0 already.
+* Delete Compliance Mode Timer if so.
+*/
+   xhci_del_comp_mod_timer(xhci, temp, wIndex);
}
if (bus_state->port_c_suspend & (1 << wIndex))
status |= 1 << USB_PORT_FEAT_C_SUSPEND;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a979cd0..9c18375 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 
@@ -397,6 +398,97 @@ static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
 
 #endif
 
+static void compliance_mode_recovery(unsigned long arg)
+{
+   struct xhci_hcd *xhci;
+   struct usb_hcd *h

090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[mat brown]

The following is formatted in line with the info here:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Kernel.org_Format
and sent as advised at the end of this bug report here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1032342

Thanks in advance for your time, I very much hope I've minimised any
wastage of that precious resource.

regards,

-mat


Summary:

090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
best 50-60 Mb/s

Description:

USB transfers to/from flash drives are very slow. Disk Utility reports
the various drives I've tried are connected at 480Mb/s, but it's rare
to see transfers faster than 50-60Mb/s at best, probably less as
nautilus only reports average speed which is skewed by the first 300Mb
being buffered.

Sometimes I get the first 300MB very fast followed by very slow and
ending with a long pause while the write buffer writes out, sometimes
they're just very slow from the start. Doesn't seem to matter if I'm
transferring one big file or lots of little files. Seems faster with
USB HDs. Flash drives I've tried so far are all working fine in other
OSes on the same machine.

Also occurring with bleeding edge kernel (which I'm using because
anything younger won't suspend properly on my machine),
3.5.0-999-generic #201207280406 SMP Sat Jul 28 08:07:29 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux.

The reason I'm reporting it here rather than at kernel.org is that I
don't think it's a kernel bug, I think it's to do with Debian/Ubuntu's
kernel patches. Because it doesn't happen in the live version of
Fedora 17 I tried, but it does happen with Debian Wheezy. Windows 7 is
also fast.

Laptop is a Toshiba L830-114.

Reproducible by just using the USB ports to transfer files to/from a
flash drive.  Transfers to/from a USB HD seem quicker but are hardly
what I'd call fast.

Keywords: usb amd64

Kernel version: Linux version 3.5.0-999-generic (apw@gomeisa) (gcc
version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201207280406 SMP Sat
Jul 28 08:07:29 UTC 2012

lsb_release -rd
Description: Ubuntu 12.04 LTS
Release: 12.04

ver_linux
Linux izumi 3.5.0-999-generic #201207280406 SMP Sat Jul 28 08:07:29
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Gnu C  gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc. This is free
software; see the source for copying conditions. There is NO warranty;
not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Gnu make   3.81
util-linux linux 2.20.1
mount  linux 2.20.1 (with libblkid and selinux support)
modutils   3.16
e2fsprogs  1.42
PPP2.4.5
Linux C Library> libc.2.15
Dynamic linker (ldd)   2.15
Procps 3.2.8
Net-tools  1.60
Kbd1.15.2
Sh-utils   8.13
Modules Loaded snd_hda_codec_hdmi snd_hda_codec_conexant
parport_pc rfcomm ppdev bnep joydev snd_hda_intel snd_hda_codec
coretemp arc4 i915 ath9k mac80211 ath9k_common ath9k_hw kvm_intel
snd_hwdep snd_pcm uvcvideo kvm drm_kms_helper ath snd_seq_midi
snd_rawmidi mei drm snd_seq_midi_event snd_seq snd_timer ath3k
snd_seq_device videobuf2_core btusb psmouse videodev videobuf2_vmalloc
snd cfg80211 bluetooth toshiba_acpi ghash_clmulni_intel
videobuf2_memops cryptd soundcore snd_page_alloc i2c_algo_bit lpc_ich
sparse_keymap serio_raw microcode wmi toshiba_bluetooth mac_hid video
lp parport atl1c

cat /proc/cpuinfo (snipped as each of four cores reports identically)

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i3-2377M CPU @ 1.50GHz
stepping : 7
microcode : 0x28
cpu MHz : 800.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer xsave avx lahf_lm arat epb xsaveopt pln pts dtherm
tpr_shadow vnmi flexpriority ept vpid
bogomips : 2993.09
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

cat /proc/modules
snd_hda_codec_hdmi 32467 1 - Live 0x
snd_hda_codec_conexant 58307 1 - Live 0x
parport_pc 32866 0 - Live 0x
rfcomm 47922 12 - Live 0x
ppdev 17113 0 - Live 0x
bnep 18315 2 - Live 0x
joydev 17693 0 - Live 0x
snd_hda_intel 34147 3 - Live 0x
snd_hda_codec 135376 3
snd_hda_codec_hdmi,snd_hda_codec_conexant,snd_hda_intel, Live
0x
coretemp 13641 0 - Live 0x
arc4 12573 2 - Live 0x
i9

RE: [PATCH] usb: storage: stop all current urbs when device is disconnected

[B, Ravi]

Hi

Thanks for the quick response.

> > 
> > > Alan you may be correct.  Let me explain, the issue occurs while 
> > > unplugging the device during Tx transfer,
> > > 1) During Tx transfer, TX-DMA is programmed to transfer the data. 
> > > 2) The TX-DMA completes the transfer and generates 
> completion interrupt. 
> > > 3) On tx completion interrupt context the URB is given back. 
> > > In normal scenario, the sequence 1 to 3 occurs during tx 
> transfers.
> > > Issue occurs when the device is unplugged while TX-DMA 
> transfer is 
> > > in progress. The DMA halts and never generates completion 
> interrupt. 
> > > In
> > 
> > What host controller driver are you using?

It is mentor controller integrated with CPPI41-DMA 

> > 
> > Why doesn't the controller hardware detect that the device fails to 
> > send handshake packets and abort the transfer?  According 
> to the USB-2 
> > spec, after three failures the controller must end the 
> transfer.  This 
> > sounds like a bug in the controller or its driver.

The usb flash drive is connected directly to root port. 
Hence when the device is disconnected, the controller does not continue (no SOF)
due to all devices connected to port are disconnected. 
Hence controller will not retry or transfer the data to device. 
This must be expected behavior.

> > 
> > > this scenario, this active request at DMA is given back when 
> > > application calls dequeue or unlink the URB. Since in 
> this scenario 
> > > since there is no timeout occurs on the URB, we expect the scsi 
> > > layer should unlink the active URB upon DISCONNECT of device.
> > 
> > Not until the command times out.
> > 
> > > In this scenario, when the DISCONNECT occur, scsi does not unlink 
> > > the active URB, this patch fixing this issue.
> > > Can you point me which function unlink the active URB 
> (which is not 
> > > returned).
> > > Let me know if you have better solution or any suggestion.
> > 
> > I would expect the command to time out and be unlinked by
> > command_abort() after 30 seconds or so, and I would expect
> > scsi_remove_host() to wait until this happens.  If this doesn't 
> > happen, it indicates a bug in the SCSI or block layers.
> 

During disconnect event in the middle of transfer, the scsi knows that the 
device no more exits, 
I think there is no need to wait for timeout for active URB, it is safe to 
unlink or cancel the active URB.

> I tried doing a similar experiment on my system.  I got rid 
> of the code that makes ehci-hcd stop retrying after a maximum 
> number of transaction errors (so that it would continue to 
> retry indefinitely), and then pulled out my USB flash drive 
> while a program was reading from it.
> 
> The result was exactly as predicted: After 30 seconds the 
> current transfer was aborted, and scsi_remove_host() waited 
> for this to happen.

Why scsi to wait for 30 seconds timeout upon receiving the DEVICE DICONNECT
Notfication ?
Have you connected the device through HUB ? 
What happen if the device connected directly to root port (without HUB).

Regards
Ravi Babu
> 
> 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 v7 00/11] usb: musb: adding multi instance support

[B, Ravi]

Hi

> 
> On 02.08.2012 14:12, Ravi Babu wrote:
> > This series of patches adds,
> > a) Multi instances support in musb driver
> > b) DT support for musb_dsps glue layer
> > c) DT support for NOP transceiver
> > 
> > AM33xx and TI81xx has dual musb controller and has two usb 
> PHY of same type.
> > This patch series uses 'phandle' based API 
> > devm_usb_get_phy_by_phandle() to get the PHY of same type. This API 
> > support is being added by Kishon's patch discussed at [1]
> > 
> > The series applies to linux-omap (master branch)
> > + Vaibhav baseport patches on his tree at [3]
> > + Kishon's multi phy patches on Felipe's branch 'xceiv'
> > + Kishon's patch on phandle at [1]
> > + AM33xx musb glue compile and bugfix patches at [4], 
> [5], [6] and [7]
> > + Damodar's recent patch at [2]
> > 
> > and have been tested on Beaglebone board.

Have you applied the above patches before applying these patches.

Ravi Babu

> 
> I would like to test these patches on a custom AM33xx board, 
> but I'm having trouble applying them. I am based on Linus' 
> master tree, and "git am" fails for 
> drivers/usb/musb/musb_dsps.c. The commits I got for that file are:
> 
> ded017ee6 usb: phy: fix return value check of usb_get_phy 
> 662dca54c usb: otg: support for multiple transceivers by a 
> single controller
> 721002ec1 usb: otg: utils: rename function name in OTG utils
> 9ecb88752 usb: musb: Add support for ti81xx platform
> 
> I wonder which branch you are based on and which tree those 
> patches should go thru eventually.
> 
> 
> Thanks,
> Daniel
> 
> --
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: stop all current urbs when device is disconnected

[Alan Stern]

On Fri, 3 Aug 2012, B, Ravi wrote:

> > > What host controller driver are you using?
> 
> It is mentor controller integrated with CPPI41-DMA 

Then you're using the musb driver?

> > > Why doesn't the controller hardware detect that the device fails to 
> > > send handshake packets and abort the transfer?  According 
> > to the USB-2 
> > > spec, after three failures the controller must end the 
> > transfer.  This 
> > > sounds like a bug in the controller or its driver.
> 
> The usb flash drive is connected directly to root port. 
> Hence when the device is disconnected, the controller does not continue (no 
> SOF)
> due to all devices connected to port are disconnected. 
> Hence controller will not retry or transfer the data to device. 
> This must be expected behavior.

Well, I suppose it's the _designed_ behavior.  But it's still arguably 
a bug.

Maybe the musb driver should be changed.  It should cancel all the 
active URBs when all the ports are disconnected or suspended.

> > > I would expect the command to time out and be unlinked by
> > > command_abort() after 30 seconds or so, and I would expect
> > > scsi_remove_host() to wait until this happens.  If this doesn't 
> > > happen, it indicates a bug in the SCSI or block layers.
> > 
> 
> During disconnect event in the middle of transfer, the scsi knows
> that the device no more exits, I think there is no need to wait for
> timeout for active URB, it is safe to unlink or cancel the active
> URB.

Actually the SCSI layer does _not_ know that the device has been
removed.  It only knows that the driver has been unbound from the
device.  The behavior is the same as if you did "rmmod usb-storage"  
while leaving the device plugged in.

Anyway, it seems clear that your patch won't help.  The new code you 
added won't run until after the 30-second timeout has expired, and by 
then it's not needed any more.

> > I tried doing a similar experiment on my system.  I got rid 
> > of the code that makes ehci-hcd stop retrying after a maximum 
> > number of transaction errors (so that it would continue to 
> > retry indefinitely), and then pulled out my USB flash drive 
> > while a program was reading from it.
> > 
> > The result was exactly as predicted: After 30 seconds the 
> > current transfer was aborted, and scsi_remove_host() waited 
> > for this to happen.
> 
> Why scsi to wait for 30 seconds timeout upon receiving the DEVICE DICONNECT
> Notfication ?

That's the timeout for all the SCSI commands.  The timeout doesn't 
change when the disconnect notification is received.

> Have you connected the device through HUB ? 

No.

> What happen if the device connected directly to root port (without HUB).

As I described above.

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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Alan Stern]

On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:

> > I don't know about that -- the logic involved in doing the processing 
> > within the resume callback isn't terribly complicated.  At least, not 
> > much more complicated than the logic involved in setting up a custom 
> > work routine as you suggest.
> 
> That's why I had the idea of pm_request_resume_and_call(dev, func)
> described in this message:
> 
> http://marc.info/?l=linux-usb&m=134377126804170&w=4
> 
> although perheps it would be better to call it something like
> pm_runtime_async_resume_and_call(dev, func).

Hmmm.  You'd probably want a version that does a "get" at the same 
time.  I suppose you would call func directly if the device was already 
resumed, without going through the workqueue?

Yes, I agree this would be a better interface then pm_runtime_get.

> > > Well, that shouldn't need the is_suspended flag at all, methinks, and the
> > > reason it does need it is because it uses pm_runtime_get().
> > 
> > Not so.  Consider your scheme.  When starting an I/O request, you call
> > pm_runtime_get_noresume() and then check to see if the device is
> > active, say by calling pm_runtime_suspended().  Suppose at that moment
> > the suspend callback has just finished and has released the private
> > spinlock.  The device's status is still RPM_SUSPENDING, so
> > pm_runtime_suspended() returns 0 and you try to carry out the I/O.
> > 
> > To fix this problem you have to synchronize the status checking with
> > the suspend/resume operations.  This means the status changes have to
> > occur under the protection of the private lock, which means a private
> > flag is needed.
> 
> What about checking if the status is RPM_ACTIVE under dev->power.lock?
> That's what rpm_resume() does, more or less.

That wouldn't solve the race described above.

> > >  Moreover,
> > > processing requests in the resume callback is not something I'd recommend
> > > to anyone, because that's going to happen when the status of the device
> > > is RPM_RESUMING, we're holding a reference on the parent (if there's one) 
> > > etc.
> > 
> > I don't see any problem with that.  The parent's child_count will be 
> > incremented while the requests are being processed regardless.  And if 
> > you've been waiting for the device to resume in order to carry out some 
> > processing, within the resume callback is the logical place to do the 
> > work.
> 
> Unless your _driver_ callback is actually executed from within a PM domain
> callback, for example, and something else may be waiting for it to complete,
> so your data processing is adding latencies to some other threads.  I'm not
> making that up, by the way, that really can happen.
> 
> And what if you are a parent waited for by a child to resume so that _it_
> can process its data?  Would you still want to process your data in the
> resume callback in that case?

Okay, those are valid reasons.  (Although a device handling I/O 
requests isn't likely to have a child with its own independent I/O 
handling.)

> > I suppose we could keep pm_runtime_get_sync as is, and just change
> > pm_runtime_get to pm_runtime_get_async (and likewise for _put).  That
> > could reduce the confusion during the changeover.
> 
> Changing pm_runtime_get() to pm_runtime_get_async() would be an improvement,
> although pm_runtime_get_but_do_not_resume_immediately() might even be better.
> Or even pm_runtime_get_but_do_not_access_hardware_when_it_returns(). ;-)
> 
> I see no reason to have any of those things, though.  Yes, they _may_ be
> useful to someone knowing the runtime PM core internals to save a few lines
> of code in some places, but generally they lead people to make serious 
> mistakes
> that tend to be difficult to debug.  For this very reason pm_runtime_get() is 
> a
> bad interface and I wish we hadn't introduced it at all.  Even if we give it
> a more descriptive name, it won't be much better.
> 
> And note how that doesn't apply to the pm_runtime_put*() family.  After all,
> doing pm_runtime_put() instead of pm_runtime_put_sync() will never lead to
> accessing registers of a suspended device.

All right.  But I still think "pm_runtime_put_async" is better than
"pm_runtime_put".  At least it forces people to think about what
they're doing.

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: [RFC][PATCH v2] usb: host: ehci-platform: add pm_runtime_xx()

[kuninori . morimoto . gx]

Hi Alan, Felipe, Greg

These are v2 of ehci/ohci-platform patches.
These are based on latest linus/master (and linux-next/mastere)

I tested these patches on R-Car H1 marzen board.
But I couldn't test suspend/resume.
So, I added [RFC] on this patch.
Please check these patches carefully

Kuninori Morimoto (2):
  usb: host: ehci-platform: add platform specific .power callback
  usb: host: ohci-platform: add platform specific .power callback

 drivers/usb/host/ehci-platform.c |   33 +
 drivers/usb/host/ohci-platform.c |   29 ++---
 include/linux/usb/ehci_pdriver.h |2 ++
 include/linux/usb/ohci_pdriver.h |2 ++
 4 files changed, 59 insertions(+), 7 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

Re: 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[Alan Stern]

On Fri, 3 Aug 2012, mat brown wrote:

> The following is formatted in line with the info here:
> https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Kernel.org_Format
> and sent as advised at the end of this bug report here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1032342
> 
> Thanks in advance for your time, I very much hope I've minimised any
> wastage of that precious resource.


> Summary:
> 
> 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at
> best 50-60 Mb/s

> The reason I'm reporting it here rather than at kernel.org is that I
> don't think it's a kernel bug, I think it's to do with Debian/Ubuntu's
> kernel patches. Because it doesn't happen in the live version of
> Fedora 17 I tried, but it does happen with Debian Wheezy. Windows 7 is
> also fast.

What mount options are used for the flash drive?  In particular, does
Ubuntu use the "sync" option?

Also, do any error messages show up in the system log during the slow 
data transfers?

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

[RFC][PATCH 1/2 v2] usb: host: ehci-platform: add platform specific .power callback

[kuninori . morimoto . gx]

This patch enables to call platform specific power callback function.

Signed-off-by: Kuninori Morimoto 
---
 drivers/usb/host/ehci-platform.c |   33 +
 include/linux/usb/ehci_pdriver.h |2 ++
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 4b1d896..679aa16 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -82,10 +82,11 @@ static int __devinit ehci_platform_probe(struct 
platform_device *dev)
 {
struct usb_hcd *hcd;
struct resource *res_mem;
+   struct usb_ehci_pdata *pdata = dev->dev.platform_data;
int irq;
int err = -ENOMEM;
 
-   BUG_ON(!dev->dev.platform_data);
+   BUG_ON(!pdata);
 
if (usb_disabled())
return -ENODEV;
@@ -101,10 +102,15 @@ static int __devinit ehci_platform_probe(struct 
platform_device *dev)
return -ENXIO;
}
 
+   if (pdata->power) /* power enable */
+   pdata->power(&dev->dev, 0, 1);
+
hcd = usb_create_hcd(&ehci_platform_hc_driver, &dev->dev,
 dev_name(&dev->dev));
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd) {
+   err = -ENOMEM;
+   goto err_power;
+   }
 
hcd->rsrc_start = res_mem->start;
hcd->rsrc_len = resource_size(res_mem);
@@ -132,12 +138,17 @@ err_release_region:
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
 err_put_hcd:
usb_put_hcd(hcd);
+err_power:
+   if (pdata->power) /* power disable */
+   pdata->power(&dev->dev, 0, 0);
+
return err;
 }
 
 static int __devexit ehci_platform_remove(struct platform_device *dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
+   struct usb_ehci_pdata *pdata = dev->dev.platform_data;
 
usb_remove_hcd(hcd);
iounmap(hcd->regs);
@@ -145,6 +156,9 @@ static int __devexit ehci_platform_remove(struct 
platform_device *dev)
usb_put_hcd(hcd);
platform_set_drvdata(dev, NULL);
 
+   if (pdata->power) /* power disable */
+   pdata->power(&dev->dev, 0, 0);
+
return 0;
 }
 
@@ -153,14 +167,25 @@ static int __devexit ehci_platform_remove(struct 
platform_device *dev)
 static int ehci_platform_suspend(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
+   struct usb_ehci_pdata *pdata = dev->platform_data;
bool do_wakeup = device_may_wakeup(dev);
+   int ret;
 
-   return ehci_suspend(hcd, do_wakeup);
+   ret = ehci_suspend(hcd, do_wakeup);
+
+   if (pdata->power) /* power disable */
+   pdata->power(dev, 1, 0);
+
+   return ret;
 }
 
 static int ehci_platform_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
+   struct usb_ehci_pdata *pdata = dev->platform_data;
+
+   if (pdata->power) /* power enable */
+   pdata->power(dev, 1, 1);
 
ehci_resume(hcd, false);
return 0;
diff --git a/include/linux/usb/ehci_pdriver.h b/include/linux/usb/ehci_pdriver.h
index 1894f42..9164000 100644
--- a/include/linux/usb/ehci_pdriver.h
+++ b/include/linux/usb/ehci_pdriver.h
@@ -41,6 +41,8 @@ struct usb_ehci_pdata {
unsignedbig_endian_mmio:1;
unsignedport_power_on:1;
unsignedport_power_off:1;
+
+   void (*power)(struct device *dev, int in_pm, int enable);
 };
 
 #endif /* __USB_CORE_EHCI_PDRIVER_H */
-- 
1.7.5.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][PATCH 2/2 v2] usb: host: ohci-platform: add platform specific .power callback

[kuninori . morimoto . gx]

This patch enables to call platform specific power callback function.

Signed-off-by: Kuninori Morimoto 
---
 drivers/usb/host/ohci-platform.c |   29 ++---
 include/linux/usb/ohci_pdriver.h |2 ++
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 670c705..03da469 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -83,10 +83,11 @@ static int __devinit ohci_platform_probe(struct 
platform_device *dev)
 {
struct usb_hcd *hcd;
struct resource *res_mem;
+   struct usb_ohci_pdata *pdata = dev->dev.platform_data;
int irq;
int err = -ENOMEM;
 
-   BUG_ON(!dev->dev.platform_data);
+   BUG_ON(!pdata);
 
if (usb_disabled())
return -ENODEV;
@@ -103,10 +104,15 @@ static int __devinit ohci_platform_probe(struct 
platform_device *dev)
return -ENXIO;
}
 
+   if (pdata->power) /* power enable */
+   pdata->power(&dev->dev, 0, 1);
+
hcd = usb_create_hcd(&ohci_platform_hc_driver, &dev->dev,
dev_name(&dev->dev));
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd) {
+   err = -ENOMEM;
+   goto err_power;
+   }
 
hcd->rsrc_start = res_mem->start;
hcd->rsrc_len = resource_size(res_mem);
@@ -134,12 +140,17 @@ err_release_region:
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
 err_put_hcd:
usb_put_hcd(hcd);
+err_power:
+   if (pdata->power) /* power disable */
+   pdata->power(&dev->dev, 0, 0);
+
return err;
 }
 
 static int __devexit ohci_platform_remove(struct platform_device *dev)
 {
struct usb_hcd *hcd = platform_get_drvdata(dev);
+   struct usb_ohci_pdata *pdata = dev->dev.platform_data;
 
usb_remove_hcd(hcd);
iounmap(hcd->regs);
@@ -147,6 +158,9 @@ static int __devexit ohci_platform_remove(struct 
platform_device *dev)
usb_put_hcd(hcd);
platform_set_drvdata(dev, NULL);
 
+   if (pdata->power) /* power disable */
+   pdata->power(&dev->dev, 0, 0);
+
return 0;
 }
 
@@ -154,12 +168,21 @@ static int __devexit ohci_platform_remove(struct 
platform_device *dev)
 
 static int ohci_platform_suspend(struct device *dev)
 {
+   struct usb_ohci_pdata *pdata = dev->platform_data;
+
+   if (pdata->power) /* power disable */
+   pdata->power(dev, 1, 0);
+
return 0;
 }
 
 static int ohci_platform_resume(struct device *dev)
 {
struct usb_hcd *hcd = dev_get_drvdata(dev);
+   struct usb_ohci_pdata *pdata = dev->platform_data;
+
+   if (pdata->power) /* power enable */
+   pdata->power(dev, 1, 1);
 
ohci_finish_controller_resume(hcd);
return 0;
diff --git a/include/linux/usb/ohci_pdriver.h b/include/linux/usb/ohci_pdriver.h
index 2808f2a..6cf973a 100644
--- a/include/linux/usb/ohci_pdriver.h
+++ b/include/linux/usb/ohci_pdriver.h
@@ -33,6 +33,8 @@ struct usb_ohci_pdata {
unsignedbig_endian_desc:1;
unsignedbig_endian_mmio:1;
unsignedno_big_frame_no:1;
+
+   void (*power)(struct device *dev, int in_pm, int enable);
 };
 
 #endif /* __USB_CORE_OHCI_PDRIVER_H */
-- 
1.7.5.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: 090c:1000 file transfer to/from USB 2.0 flash drive, via 3.0 port at best 50-60 Mb/s

[mat brown]

On Fri, Aug 3, 2012 at 3:32 AM, Alan Stern  wrote:
>
> What mount options are used for the flash drive?  In particular, does
> Ubuntu use the "sync" option?
>
> Also, do any error messages show up in the system log during the slow
> data transfers?
>
> Alan Stern
>

mount reports the following:

/dev/sdb1 on /media/littlun type vfat
(rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)

Nothing shows up in syslog during transfers.

One thing I hadn't tried until a moment ago was an fs other than
fat32.  Same issue occurs with ext4.


-mat
--
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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Ming Lei]

On Fri, Aug 3, 2012 at 10:20 AM, Alan Stern  wrote:
> On Thu, 2 Aug 2012, Rafael J. Wysocki wrote:

> Hmmm.  You'd probably want a version that does a "get" at the same
> time.  I suppose you would call func directly if the device was already
> resumed, without going through the workqueue?

Maybe it isn't good, the 'func' might not be run in the current context
(irq context or some spinlock is held).

>> And what if you are a parent waited for by a child to resume so that _it_
>> can process its data?  Would you still want to process your data in the
>> resume callback in that case?

Looks the child is always resumed after its parent completes the resuming,
and current pm_runtime_get doesn't delay the resume of the parent, and
just make the .runtime_resume run in another context.

Also are there actual examples about the above situation?

>
> Okay, those are valid reasons.  (Although a device handling I/O
> requests isn't likely to have a child with its own independent I/O
> handling.)

IMO, the .runtime_resume callback can handle the IO things easily
via scheduling worker function if the driver don't want to delay
its children's resume.

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] usb: storage: stop all current urbs when device is disconnected

[B, Ravi]

 

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu] 
> Sent: Friday, August 03, 2012 7:15 AM
> To: B, Ravi
> Cc: Matthew Dharm; Greg Kroah-Hartman; 
> linux-usb@vger.kernel.org; usb-stor...@lists.one-eyed-alien.net
> Subject: RE: [PATCH] usb: storage: stop all current urbs when 
> device is disconnected
> 
> On Fri, 3 Aug 2012, B, Ravi wrote:
> 
> > > > What host controller driver are you using?
> > 
> > It is mentor controller integrated with CPPI41-DMA
> 
> Then you're using the musb driver?
> 
> > > > Why doesn't the controller hardware detect that the 
> device fails 
> > > > to send handshake packets and abort the transfer?  According
> > > to the USB-2
> > > > spec, after three failures the controller must end the
> > > transfer.  This
> > > > sounds like a bug in the controller or its driver.
> > 
> > The usb flash drive is connected directly to root port. 
> > Hence when the device is disconnected, the controller does not 
> > continue (no SOF) due to all devices connected to port are 
> disconnected.
> > Hence controller will not retry or transfer the data to device. 
> > This must be expected behavior.
> 
> Well, I suppose it's the _designed_ behavior.  But it's still 
> arguably a bug.
> 
> Maybe the musb driver should be changed.  It should cancel 
> all the active URBs when all the ports are disconnected or suspended.
> 
> > > > I would expect the command to time out and be unlinked by
> > > > command_abort() after 30 seconds or so, and I would expect
> > > > scsi_remove_host() to wait until this happens.  If this doesn't 
> > > > happen, it indicates a bug in the SCSI or block layers.
> > > 
> > 
> > During disconnect event in the middle of transfer, the scsi 
> knows that 
> > the device no more exits, I think there is no need to wait 
> for timeout 
> > for active URB, it is safe to unlink or cancel the active URB.
> 
> Actually the SCSI layer does _not_ know that the device has 
> been removed.  It only knows that the driver has been unbound 
> from the device.  The behavior is the same as if you did 
> "rmmod usb-storage"  
> while leaving the device plugged in.
> 
> Anyway, it seems clear that your patch won't help.  The new 
> code you added won't run until after the 30-second timeout 
> has expired, and by then it's not needed any more.

Alan, I did not understand, if the driver has unbound from the device, what is 
the need to wait for 30seconds timeout to cancel the URB. 
Can you explain in detail.

> 
> > > I tried doing a similar experiment on my system.  I got 
> rid of the 
> > > code that makes ehci-hcd stop retrying after a maximum number of 
> > > transaction errors (so that it would continue to retry 
> > > indefinitely), and then pulled out my USB flash drive while a 
> > > program was reading from it.
> > > 
> > > The result was exactly as predicted: After 30 seconds the current 
> > > transfer was aborted, and scsi_remove_host() waited for this to 
> > > happen.
> > 
> > Why scsi to wait for 30 seconds timeout upon receiving the DEVICE 
> > DICONNECT Notfication ?
> 
> That's the timeout for all the SCSI commands.  The timeout 
> doesn't change when the disconnect notification is received.

During disconnect, it is better to cancel all queued and active current URB, 
why to wait for 30sec timeout.
The API usb_stor_stop_transport() does the same. This API is safe it only 
unlink if there is active URB.

> 
> > Have you connected the device through HUB ? 
> 
> No.
> 
> > What happen if the device connected directly to root port 
> (without HUB).
> 
> As I described above.
> 
> 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

kernel panic when called usb_control_msg()

[y b]

Hi,
kernel panic when called usb_control_msg(), like this:
   usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
XR_SET_REG, USB_DIR_OUT | USB_TYPE_VENDOR, value, regnum | (block <<
8), NULL, 0, 5000)
The kernel's version is 2.6.33_rc4, but I think it will happen in
lastest statable version too.

# uname -a
Linux (none) 2.6.33-rc4 #268 PREEMPT Fri Aug 3 05:28:27 EDT 2012
armv5tejl unknown

Unable to handle kernel NULL pointer dereference at virtual address 003c
pgd = c7134000
[003c] *pgd=c711e031, *pte=, *ppte=
Internal error: Oops: 17 [#1] PREEMPT
last sysfs file:
Modules linked in:
CPU: 0Not tainted  (2.6.33-rc4 #287)
PC is at musb_start_urb+0x58/0x760
LR is at musb_urb_enqueue+0x658/0x768
pc : []lr : []psr: 6093
sp : c7005aa8  ip : c7849948  fp : c7005b24
r10:   r9 : c7849800  r8 : c789c038
r7 : c701c480  r6 : c78498dc  r5 : 0001  r4 : c7c6f7c0
r3 : c7c6f7c0  r2 :   r1 : fee00400  r0 : 
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: c7134000  DAC: 0015
Process COM3 (pid: 1022, stack limit = 0xc7004270)
Stack: (0xc7005aa8 to 0xc7006000)
5aa0:   0001 c0027b6c c7004000 0010 c7005adc c7005ac8
5ac0: c02c7c28 c00353c8  febfd000 c7005b7c c7c6f7c0  
5ae0: fee00400 c789c038 c7849948 0010 c7005b14 c7005b00 c02c75e4 c7c6f7c0
5b00: 0001 c7849948 c701c480 c789c038 c7849800 0010 c7005b7c c7005b28
5b20: c02373bc c0235c50 376c0f73 c03ed1ac c7849800 c7c6f7cc  c78498dc
5b40:  c7005b50  6013 c7005b7c c7c8f920 0010 
5b60: c701c480  c7849800  c7005c34 c7005b80 c021e6a8 c0236d74
5b80:  0020 0003 0001 c04e7140 c03c2420 c7005bc4 c7005ba8
5ba0: c0097140 c00353c8 c04e7140 c700ae00 c03c240c c021f3ac c7005be4 c7005bc8
5bc0: c0099b00 c00353c8 c03c240c c04e7140 c05001a0 0001 c7005c04 c7005be8
5be0: c00984b8 c00353c8 c05001a0  c03c240c c04e7398 c7005c44 c7005c08
5c00: c0099564 c00353c8 c7005c2c c789c038 c789c000  0010 c7005c9c
5c20:   c7005c54 c7005c38 c021ede4 c021dec4 c7005c58 
5c40: c701c480  c7005c8c c7005c58 c02202e8 c021eb70 0001 c7005c5c
5c60: c7005c5c  c7005c8c  c7c8f920  0412 0040
5c80: c7005ccc c7005c90 c0220550 c02202b0 8600 c789c000 c7005cd4 
5ca0: c009a07c  0002 0002 c72f7f00 c7020400 c7c8cea0 c7c8cecc
5cc0: c7005cfc c7005cd0 c02322b4 c0220484  0412  
5ce0:   c7005d0c c71f1c00 c7005d14 c7005d00 c0232300 c023226c
5d00: 0cbd c71f1c00 c7005d3c c7005d18 c02324b4 c02322cc c71f1c00 c7020400
5d20: c7005d78  c7020400 c7c8cea0 c7005d5c c7005d40 c022ed8c c0232484
5d40: 0cbd 8a20 c7c8cedf  c7005dfc c7005d60 c01bfea8 c022ed24
5d60: c01a6c34  00c9  c7020424  0500 0005
5d80: 0cbd 8a3b 7f1c0300 01000415 1a131100 170f1200 0016 2580
5da0: 2580 0500 0004 0cbd 8a20 7f1c0300 01000415 1a131100
5dc0: 170f1200 0016 2580 2580 c7005e0c c7020400 c7020400 41ca6544
5de0: c7c8fb60 41ca6544 c7004000 c700a900 c7005e74 c7005e00 c01c0168 c01bfa84
5e00: c7005e3c c7005e10 c00373f4 c00353c8 0004 c7005e20 c005017c c7304400
5e20: c7304400 c7304000 0001 c7004000 c7005e54 c7005e40 c71f1c00 c7020400
5e40: c7005e64 c7005e50 c022e7f0 c0230d64 5409  c7020400 5402
5e60: 41ca6544 c7c8fb60 c7005e94 c7005e78 c01c04f4 c01bff20 5402 fdfd
5e80: 41ca6544 c7c8fb60 c7005eb4 c7005e98 c01bd5dc c01c0384 5402 fdfd
5ea0: c7020400 c7c8fb60 c7005eec c7005eb8 c01bb980 c01bd508 c00373f4 c00353c8
5ec0: a013 c03fbf00 c700a900 5402 41ca6544 c700a900 41ca6544 
5ee0: c7005f0c c7005ef0 c00aabd4 c01bb04c c7420528 c700a900 0065 c700a900
5f00: c7005f7c c7005f10 c00ab2c4 c00aabb0 c01bd5e4 c71b92a0 5019c987 
5f20: c7028000 c7c76800 4002 c7005f70 0039 4002 c7004000 0964
5f40: c7005f6c c7005f50 c009db60 c01ba9e8 c7005f7c 0065 41ca6544 5402
5f60: c700a900 c00280a4 c7004000  c7005fa4 c7005f80 c00ab360 c00aad5c
5f80: 0005 0001 41ca6544 8a20  0036  c7005fa8
5fa0: c0027f20 c00ab330 41ca6544 8a20 0065 5402 41ca6544 170f1200
5fc0: 41ca6544 8a20  0036 0065 41caa678  41caa64c
5fe0: 41ca6568 41ca6540 402be080 402be094 6010 0065 9f3c1ae4 5d574b3c
Backtrace:
[] (musb_start_urb+0x0/0x760) from []
(musb_urb_enqueue+0x658/0x768)
[] (musb_urb_enqueue+0x0/0x768) from []
(usb_hcd_submit_urb+0x7f4/0x8fc)
[] (usb_hcd_submit_urb+0x0/0x8fc) from []
(usb_submit_urb+0x284/0x2a0)
[] (usb_submit_urb+0x0/0x2a0) from []
(usb_start_wait_urb+0x48/0xb4)
 r7: r6:c701c480 r5: r4:c7005c58
[] (usb_start_wait_urb+0x0/0xb4) from []
(usb_control_msg+0xdc/0x100)
 r8:0040 r7:0412 r6: r5:c7c8f920 

Re: [PATCH 2/2] OMAP4: otg: phy: remove uggly mdelay(200)

[ABRAHAM, KISHON VIJAY]

Hi,

On Thu, Jul 5, 2012 at 2:12 PM, Ruslan Bilovol  wrote:
> The original issue with powering on the PHY (and using
> 200 ms delay after this) is not related to internal
> processes in the PHY but is in the incorrect charger
> detection feature usage.
>
> Now when it is fixed, we can safely remove this uggly

So is this 200ms delay related to incorrect charger detection? How is
it now fixed without the delay?

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

Re: Kernel panic when called usb_control_msg()

[Felipe Balbi]

Hi,

On Fri, Aug 03, 2012 at 11:19:36AM +0800, taylor Wang wrote:
> Hello,
> kernel panic when called usb_control_msg(), like this:
>usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
> XR_SET_REG, USB_DIR_OUT | USB_TYPE_VENDOR, value, regnum | (block << 8),
> NULL, 0, 5000)
> The kernel's version is 2.6.33_rc4, but I think it will happen in lastest
> statable version too.

thanks for that, but please read Documentation/SubmittingPatches and
Documentation/SubmitChecklist. I need patches on the correct format.

-- 
balbi


signature.asc
Description: Digital signature