RE: Linux USB file storage gadget with new UDC
Hi, > > > > > > > > # insmod kagen2_udc.ko > > > > # insmod g_file_storage.ko file=/dev/mmcblk0 > > > > gadget: controller 'kagen2_usb' not recognized > > > > > > this should have caught your attention!! Also, rebase to a newer > > > kernel as > > that > > > message has already been dropped. > > > > > > > The udc_start() function is being called now. Before this, it was not > > called because of driver->max_speed checking in udc_start(). After > > udc_start(), which function is to be called when the gadget device is > > connected to the host PC? > > > > Thanks. I will look at the "controller 'kagen2_usb' not recognized" message. > > The development is being done on arm9 architecture. I am afraid it is > > not possible to move to a newer kernel now. > > fair enough. Just to help you out, I believe that message will be under > drivers/usb/gadget/gadget_chips.h: > > http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=blob;f=drivers/usb /gad > get/gadget_chips.h;h=a8855d0b7f3bdf19fbdc76eab8a25992f07884b0;hb=76e1 > 0d158efb6d4516018846f60c2ab5501900bc > > note that you must add your gadget_is_kagen2() and check for it on > usb_gadget_controller_number(). Also keep in mind that this doesn't exist > anymore for recent kernels. > Thanks, I got it done. I can insmod the g_file_storage.ko without the "controller 'kagen2_usb' not recognized" message. After that, can I simply connect the usb cable to the host PC? Because the PC says "USB device not recognised" when I do so. I have registered the irq routine in kagen2_udc.ko, and it is not called when usb cable is plugged in. What can go wrong? # insmod kagen2_udc.ko # # insmod g_file_storage.ko file=/dev/mmcblk0 gadget: No serial-number string provided! gadget: File-backed Storage Gadget, version: 1 September 2010 gadget: NOTE: This driver is deprecated. Consider using g_mass_storage instead. gadget: Number of LUNs=1 g_file_storage gadget-lun0: ro=0, nofua=0, file: /dev/mmcblk0 thanks, victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- 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 v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
Hi, On 12/14/2012 07:44 PM, Paul Walmsley wrote: > Hi > > On Fri, 14 Dec 2012, Tony Lindgren wrote: > >> Paul, what about this patch? Looks like you've acked the other clock >> patches in this series but not this one? > > I commented on it briefly here: > > https://patchwork.kernel.org/patch/1838111/ > > Maybe Benoît could comment here, but it looks to me (based on a > superficial look at the hardware clock tree data) that these clock nodes > should exist. In an ideal world, we'd be able to get back to the > autogeneration of this clock data. I'm not sure to understand either the rational for that patch. What the point of merging the two nodes? I mean, we can do it, but AFAIR, we have always decided to use atomic node instead of big nodes that handle everything. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb/gadget: allocate & giveback serial ports instead hard code them
This patch removes gserial_setup() and gserial_cleanup() and adds
gserial_alloc_line() and gserial_free_line() to replace them.
The initial setup of u_serial happens now on module load time. A
maximum of four TTY ports can be requested which is the current limit.
In theory we could extend this limit, the hard limit is the number of
available endpoints.
alloc_tty_driver() is now called at module init time with the max
available ports. The per-line footprint here is on 32bit is 3 * size of
pointer + 60 bytes (for cdevs).
The remaining memory (struct gs_port) is allocated once a port is
requested.
With this change it is possible to load g_multi and g_serial at the same
time. GS0 receives the module that is loaded first, GS1 is received by
the next module and so on. With the configfs interface the port number
can be exported and the device node is more predictable. Nothing changes
for g_serial and friends as long as one module is used.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/gadget/acm_ms.c | 10 +-
drivers/usb/gadget/cdc2.c |9 +-
drivers/usb/gadget/dbgp.c | 10 +-
drivers/usb/gadget/f_acm.c|3 -
drivers/usb/gadget/f_obex.c |4 -
drivers/usb/gadget/f_serial.c |4 -
drivers/usb/gadget/multi.c| 12 +-
drivers/usb/gadget/nokia.c| 37 +++--
drivers/usb/gadget/serial.c | 31 +++--
drivers/usb/gadget/u_serial.c | 306 -
drivers/usb/gadget/u_serial.h |8 +-
11 files changed, 228 insertions(+), 206 deletions(-)
diff --git a/drivers/usb/gadget/acm_ms.c b/drivers/usb/gadget/acm_ms.c
index 35cbe72..eb0fbda 100644
--- a/drivers/usb/gadget/acm_ms.c
+++ b/drivers/usb/gadget/acm_ms.c
@@ -111,6 +111,7 @@ FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
static struct fsg_common fsg_common;
/*-*/
+static unsigned char tty_line;
/*
* We _always_ have both ACM and mass storage functions.
@@ -125,7 +126,7 @@ static int __init acm_ms_do_config(struct usb_configuration
*c)
}
- status = acm_bind_config(c, 0);
+ status = acm_bind_config(c, tty_line);
if (status < 0)
return status;
@@ -152,7 +153,7 @@ static int __init acm_ms_bind(struct usb_composite_dev
*cdev)
void*retp;
/* set up serial link layer */
- status = gserial_setup(cdev->gadget, 1);
+ status = gserial_alloc_line(&tty_line);
if (status < 0)
return status;
@@ -188,14 +189,13 @@ static int __init acm_ms_bind(struct usb_composite_dev
*cdev)
fail1:
fsg_common_put(&fsg_common);
fail0:
- gserial_cleanup();
+ gserial_free_line(tty_line);
return status;
}
static int __exit acm_ms_unbind(struct usb_composite_dev *cdev)
{
- gserial_cleanup();
-
+ gserial_free_line(tty_line);
return 0;
}
diff --git a/drivers/usb/gadget/cdc2.c b/drivers/usb/gadget/cdc2.c
index 379df67..16911a5 100644
--- a/drivers/usb/gadget/cdc2.c
+++ b/drivers/usb/gadget/cdc2.c
@@ -108,6 +108,7 @@ static u8 hostaddr[ETH_ALEN];
/*-*/
+static unsigned char tty_line;
/*
* We _always_ have both CDC ECM and CDC ACM functions.
*/
@@ -124,7 +125,7 @@ static int __init cdc_do_config(struct usb_configuration *c)
if (status < 0)
return status;
- status = acm_bind_config(c, 0);
+ status = acm_bind_config(c, tty_line);
if (status < 0)
return status;
@@ -157,7 +158,7 @@ static int __init cdc_bind(struct usb_composite_dev *cdev)
return status;
/* set up serial link layer */
- status = gserial_setup(cdev->gadget, 1);
+ status = gserial_alloc_line(&tty_line);
if (status < 0)
goto fail0;
@@ -183,7 +184,7 @@ static int __init cdc_bind(struct usb_composite_dev *cdev)
return 0;
fail1:
- gserial_cleanup();
+ gserial_free_line(tty_line);
fail0:
gether_cleanup();
return status;
@@ -191,7 +192,7 @@ static int __init cdc_bind(struct usb_composite_dev *cdev)
static int __exit cdc_unbind(struct usb_composite_dev *cdev)
{
- gserial_cleanup();
+ gserial_free_line(tty_line);
gether_cleanup();
return 0;
}
diff --git a/drivers/usb/gadget/dbgp.c b/drivers/usb/gadget/dbgp.c
index 41eb98d..986fc51 100644
--- a/drivers/usb/gadget/dbgp.c
+++ b/drivers/usb/gadget/dbgp.c
@@ -231,6 +231,10 @@ static void dbgp_unbind(struct usb_gadget *gadget)
gadget->ep0->driver_data = NULL;
}
+#ifdef CONFIG_USB_G_DBGP_SERIAL
+static unsigned char tty_line;
+#endif
+
static int __init dbgp_configure_endpoints(struct usb_gadget *gadget)
{
int stp;
@@ -268,7 +272,7 @@ static int __init dbgp_configure_endpoints(struct
usb_gadget *gadget)
dbgp.serial->in->desc = &i_desc;
dbgp
Re: Bug. Can't read uvcvideo (usb video / webcams) devices
On Mon, 17 Dec 2012, [KOI8-R] � wrote: > Guys, possibly found bug in usb host controller. This is not a new bug; it has been known for many, many years. The ehci-hcd driver does not allocate periodic schedules very well for full-speed and low-speed devices. > Attempting to read /dev/video0 for USB video device gives: > libv4l2: error turning on stream: No space left on device > > The camera: > Bus 002 Device 006: ID 18ec:3299 Arkmicro Technologies Inc. > > The hardware on that machine, is ok. I also have win7 installed and > the camera works in it. > I tested this camera on other two machines with Ubuntu 12.10 and it > works out of the box (luvcview, guvcview). Actually, the camera does not seem to be working properly. Did you notice these lines in the log? [ 373.762871] usb 1-1.6: new full-speed USB device number 4 using ehci_hcd [ 373.855116] usb 1-1.6: not running at top speed; connect to a high speed hub The camera should be running at high speed -- at least, it claims to support high speed -- but it's only using full speed. > I tested it with the latest mainline kernel, the bug still exists. Yes. I'm afraid this bug isn't going to be fixed any time soon. Fixing it will be a pretty big job; it's not a simple bug. > Here is the link to bug at Ubuntu's launchpad: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088395 > > Necessary files attached. 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: [Suggestion] drivers/usb/host/ohci* : not setting urb->hcpriv = NULL after kfree it.
On Mon, 17 Dec 2012, Chen Gang wrote: > 于 2012年12月17日 11:08, Alan Stern 写道: > > It is pretty much as I explained in my previous email. > > > > finish_urb calls usb_free_priv while holding the lock. Then while > > still holding the lock, it calls usb_hcd_unlink_urb_from_ep. > > > > In addition, ohci_urb_dequeue calls usb_hcd_check_unlink_urb while > > holding the lock, and does nothing if the return value is nonzero. > > > > So all you need to do is verify that after usb_hcd_unlink_urb_from_ep > > runs, usb_hcd_check_unlink_urb will always return a nonzero value. In > > fact, it will return -EIDRM -- until the next time the URB is submitted > > and usb_hcd_link_urb_to_ep is called. > > it is true for ohci_urb_dequeue. > how about finish_unlinks and takeback_td in drives/usb/host/ohci-q.c ? > (they also can call finish_urb). Those routines, like almost all the rest of the driver, look at TDs that haven't been processed yet and URBs that haven't been completed yet. Once a TD is processed, it is freed. Since finish_urb isn't called until all the TDs in an URB have been processed, urb->hcpriv will be a valid pointer for any URB encountered. The only places where this isn't true is while an URB is being submitted. The submission routines are careful to free all the private data structures if the URB is not accepted. 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: Device configuration fails on superspeed, succeeds on highspeed
On Sun, 16 Dec 2012, Vincent Pelletier wrote: > Le dimanche 16 décembre 2012 20:46:38, Vincent Pelletier a écrit : > > I checked the specs, and the warnings about wMaxPacketSize seem > > justified (although it's unclear to me wether wMaxPacketSize is > > restricted to exactly 512B in HS, or only upper-bound at 512B). > > Another reply to myself: > Tested USB device uses a Cypress FX2LP: > > http://www.summitsoftconsulting.com/picts/iti_pcb_top.jpg > > I checked the FX2LP specs, and endpoint 1 in both directions is hardwired to > wMaxPacketSize of 64. I believe the FX2LP is quite widespread (judging by the > availability of a GPL toolchain for it and two CLI tools to send its > firmware), so those warnings might cause redundant bug reports. It does seem odd that people would buy and use these chips even though they are explicitly in violation of the USB specification. A device containing one of these things could never pass the USB-CV verification test. It may be possible for xhci-hcd to work around the bug (by internally changing wMaxPacketSize to 512). 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/gadget: allocate & giveback serial ports instead hard code them
On Mon, Dec 17, 2012 at 02:37:17PM +0100, Sebastian Andrzej Siewior wrote: > diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c > index 60937d0..93c5b4c 100644 > --- a/drivers/usb/gadget/nokia.c > +++ b/drivers/usb/gadget/nokia.c > @@ -191,8 +203,10 @@ static int __init nokia_bind(struct usb_composite_dev > *cdev) > err_usb: > gether_cleanup(); > err_ether: > - gserial_cleanup(); > -err_serial: > + cur_line--; > + while (cur_line > 0) Here it should be >= > + gserial_free_line(tty_lines[cur_line--]); > + > gphonet_cleanup(); > err_phonet: > return status; > diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c > index 4816f49..eaad0ca 100644 > --- a/drivers/usb/gadget/serial.c > +++ b/drivers/usb/gadget/serial.c > @@ -209,7 +222,9 @@ static int __init gs_bind(struct usb_composite_dev *cdev) > return 0; > > fail: > - gserial_cleanup(); > + cur_line--; > + while (cur_line > 0) > + gserial_free_line(tty_lines[cur_line]); And this should be >= and a -- of cur_line is required. > return status; > } > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget zero: avoid unnecessary reinit of data in f_sourcesink
On Thu, Dec 13, 2012 at 03:11:19PM +0100, Armando Visconti wrote: > In the IN case, since the USB request is allocated only when > the source/sink function is started and never freed, the USB ept > buffer needs to be inited only at the beginning. This change ^^ > results into a more performant g_zero module, especially when > 'pattern=1' is selected. Besides that the patch looks fine :) > Signed-off-by: Armando Visconti Sebastian -- 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: USB issue with kernel 3.6
On Sun, 16 Dec 2012, Piergiorgio Sartor wrote:
> Hi Alan,
>
> I applied the modifications you suggested, this is the output:
>
> [ 110.922009] ehci_hcd :00:0b.1: async off
> [ 209.362134] ehci_hcd :00:0b.1: async on
> [ 241.794760] ehci_hcd :00:0b.1: alan start cur time 4294908992 last
> scan 4294878606
> [ 241.794774] ehci_hcd :00:0b.1: command 10035 cmd reg 10035 status reg
> e008
> [ 241.794779] ehci_hcd :00:0b.1: async list:
> [ 241.794787] ehci_hcd :00:0b.1: qh 880149fe7800 hw
> 8800af80 dma af80 next 880146ce3f80 hw_next af800c62
> [ 241.794795] ehci_hcd :00:0b.1: qh 880146ce3f80 hw
> 8800af800c60 dma af800c60 next 880146ce3780 hw_next af800d22
> [ 241.794801] ehci_hcd :00:0b.1: qh 880146ce3780 hw
> 8800af800d20 dma af800d20 next 880147776680 hw_next af800ae2
> [ 241.794808] ehci_hcd :00:0b.1: qh 880147776680 hw
> 8800af800ae0 dma af800ae0 next 8801478bf380 hw_next af800a22
> [ 241.794815] ehci_hcd :00:0b.1: qh 8801478bf380 hw
> 8800af800a20 dma af800a20 next 88014070da00 hw_next af800f02
> [ 241.794821] ehci_hcd :00:0b.1: qh 88014070da00 hw
> 8800af800f00 dma af800f00 next 8801407d3800 hw_next af800de2
> [ 241.794828] ehci_hcd :00:0b.1: qh 8801407d3800 hw
> 8800af800de0 dma af800de0 next 8801478bfc80 hw_next af800782
> [ 241.794834] ehci_hcd :00:0b.1: qh 8801478bfc80 hw
> 8800af800780 dma af800780 next 88014079e480 hw_next af800ba2
> [ 241.794841] ehci_hcd :00:0b.1: qh 88014079e480 hw
> 8800af800ba0 dma af800ba0 next 8801478bf780 hw_next af8008a2
> [ 241.794847] ehci_hcd :00:0b.1: qh 8801478bf780 hw
> 8800af8008a0 dma af8008a0 next 8801478bfd00 hw_next af800962
> [ 241.794854] ehci_hcd :00:0b.1: qh 8801478bfd00 hw
> 8800af800960 dma af800960 next (null) hw_next af82
> [ 241.794861] ehci_hcd :00:0b.1: This qh link time 4294878614 enqueue
> time 4294878614 td token 1f8c80 ov token 0
> [ 241.794869] ehci_hcd :00:0b.1: qh 8801478bfd00 naf82 info
> 4200220e 4000 qtd af820540
> [ 241.794876] ehci_hcd :00:0b.1: overlay td 8800af800970 naf820d80
> 0001 t p0=af883a9f
> [ 241.794884] ehci_hcd :00:0b.1: dma af820d80 td 8800af820d80
> naf820960 0001 t001f8c80 p0=af883a80
> [ 241.794892] ehci_hcd :00:0b.1: dummy af820960 td 8800af820960
> n0001 0001 t0040 p0=
> [ 241.805935] ehci_hcd :00:0b.1: giveback urb 8801455fa300 actual 0
> [ 241.805943] ehci_hcd :00:0b.1: alan end
This confirms it. The async schedule isn't running, even though it is
turned on and the status register says that it is running.
> The first "async off" happened, I guess correctly,
> when the hot-plug settled and all the HDDs where
> in place as expected.
> The "async on" happened as soon as I started to
> read 10 HDDs in parallel, I think correctly too.
>
> After few seconds, this time without any "help",
> the problem appeared with the log as reported.
>
> I noticed several "async on/off" in dmesg, it
> seems to me all were consistent.
This is all what one would expect in normal operation.
It seems clear that we aren't going to be able to find the cause of
the bug. So let's try another approach: We'll change the commit you
identified as the one where the problems began.
The patch below will prevent the driver from unlinking any idle QHs
from the async schedule. This is a little overboard, because even
before that commit they did get unlinked, one at a time. Still, let's
see if this prevents the problem. (You should apply this on top of the
other patches.)
Alan Stern
Index: usb-3.7/drivers/usb/host/ehci-q.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-q.c
+++ usb-3.7/drivers/usb/host/ehci-q.c
@@ -1347,7 +1347,6 @@ static void scan_async (struct ehci_hcd
} else if (list_empty(&qh->qtd_list)
&& qh->qh_state == QH_STATE_LINKED) {
qh->unlink_cycle = ehci->async_unlink_cycle;
- check_unlinks_later = true;
} else if (temp != 0)
goto rescan;
}
--
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 v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
On 12/17/2012 10:13 AM, Benoit Cousson wrote: > Hi, > > On 12/14/2012 07:44 PM, Paul Walmsley wrote: >> Hi >> >> On Fri, 14 Dec 2012, Tony Lindgren wrote: >> >>> Paul, what about this patch? Looks like you've acked the other clock >>> patches in this series but not this one? >> >> I commented on it briefly here: >> >> https://patchwork.kernel.org/patch/1838111/ >> >> Maybe Benoît could comment here, but it looks to me (based on a >> superficial look at the hardware clock tree data) that these clock nodes >> should exist. In an ideal world, we'd be able to get back to the >> autogeneration of this clock data. > > I'm not sure to understand either the rational for that patch. What the > point of merging the two nodes? > I mean, we can do it, but AFAIR, we have always decided to use atomic > node instead of big nodes that handle everything. > I can see a similar thing done for mcbsp clocks (e.g. /* Merged func_mcbsp1_gfclk into mcbsp1 */), mmc clocks, timer clocks, mcasp clock, and sgx clock. i.e. The clock sel (mux) is combined with clock gate. I don't see why USB host has to be done differently. Were exceptions made for the above clocks in the auto generation code? The problem from driver point of view is that it has to manage an additional clock per port. Not a big deal, but I thought it could be avoided. regards, -roger -- 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: MUSB-HDRC Gadget driving VBUS inappropriately
On Fri, Dec 14, 2012 at 05:38:10PM -0800, ian coolidge wrote: > Felipe, Tony, Grazvydas, Thanks for the responses, > > On Fri, Dec 14, 2012 at 4:13 AM, Felipe Balbi wrote: > > > Hi, > > > > On Fri, Dec 14, 2012 at 02:13:07PM +0200, Grazvydas Ignotas wrote: > > > On Fri, Dec 14, 2012 at 11:53 AM, Ian Coolidge > > wrote: > > > > we find that with about a 2% chance, the gadget comes up in some kind > > of firmware failed state, driving VBUS. > > > > In this condition, we found that MUSB_DEVCTL_SESSION bit was set. > > > > I understand this to be indicative of MUSB thinking it is in host > > mode, which agrees with the driven VBUS. > > > > Further, in this state, I found that usually, there was one interrupt > > from twl4030_usb, but NO interrupts from musb-hdrc. > > > > > > I'm also also often seeing this and don't know any workaround except > > > powercycling the board :( > > > This was kind or relieved for me after I changed it to deinit musb on > > > shutdown/reset (3.3 should have that patch merged), however if you > > > randomly reset the board, there is still something like 30-50% chance > > > musb will come up dead, and on proper reset it's still something like > > > 5% chance like you reported. > > > > hehe, then you should've reported earlier :-) > > > > Anyway, I really think this has something to do with some bogus > > set_vbus() calls. > > > > Likely that looking at probe() path for checks for MUSB_DEVCTL_VBUS will > > probably show you something which is wrong. Maybe the driver is assuming > > that if VBUS bitfield is zero, then it kicks host side, or something. > > > > Go over that part of the code and you probably will find something. > > > > -- > > balbi > > > > So, I did some more testing, just printing out MUSB_DEVCTL each time. At > omap2430.c "init", > musb_probe()->musb_init_controller()->omap2430_musb_init(), > I always saw 0x80. This corresponds to MUSB_DEVCTL_BDEVICE. > It appears, then, that the MUSB is initialized correctly, but becomes bad > somehow. I'll continue to dig into this, but it would be nice to have some > simple abstract description of what the SESSION bit actually does here. > It's used as both an input and an output throughout the MUSB Linux driver, > and judging by comments, appears to have different behavior in different > configurations. Felipe? Session bit, really means a session, a USB session. It has different meanings (to some extent) when working with Host or Gadget. For Gadget mode, the session bit also triggers SRP, on host mode, maybe it's used to start sourcing VBUS, who knows. Also look at the usage of musb->is_active. That's a flag use for host mode. IIRC, it tells other parts of the driver to connect the vbus charge pump, but my memory fails now :-s -- balbi signature.asc Description: Digital signature
Re: Linux USB file storage gadget with new UDC
On Mon, Dec 17, 2012 at 04:12:13PM +0800, victor wrote: > Hi, > > > > > > > > > > > # insmod kagen2_udc.ko > > > > > # insmod g_file_storage.ko file=/dev/mmcblk0 > > > > > gadget: controller 'kagen2_usb' not recognized > > > > > > > > this should have caught your attention!! Also, rebase to a newer > > > > kernel as > > > that > > > > message has already been dropped. > > > > > > > > > > The udc_start() function is being called now. Before this, it was not > > > called because of driver->max_speed checking in udc_start(). After > > > udc_start(), which function is to be called when the gadget device is > > > connected to the host PC? > > > > > > Thanks. I will look at the "controller 'kagen2_usb' not recognized" > message. > > > The development is being done on arm9 architecture. I am afraid it is > > > not possible to move to a newer kernel now. > > > > fair enough. Just to help you out, I believe that message will be under > > drivers/usb/gadget/gadget_chips.h: > > > > > http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=blob;f=drivers/usb > /gad > > get/gadget_chips.h;h=a8855d0b7f3bdf19fbdc76eab8a25992f07884b0;hb=76e1 > > 0d158efb6d4516018846f60c2ab5501900bc > > > > note that you must add your gadget_is_kagen2() and check for it on > > usb_gadget_controller_number(). Also keep in mind that this doesn't exist > > anymore for recent kernels. > > > > Thanks, I got it done. I can insmod the g_file_storage.ko without the > "controller 'kagen2_usb' not recognized" message. After that, can I simply > connect the usb cable to the host PC? Because the PC says "USB device not > recognised" when I do so. I have registered the irq routine in > kagen2_udc.ko, and it is not called when usb cable is plugged in. What can > go wrong? from this point on, you need to read your HW documentation. Maybe you're using wrong IRQ number ? Who knows. I have no clue how kagen2 works and can't help anymore. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
On 12/17/2012 05:13 PM, Roger Quadros wrote: > On 12/17/2012 10:13 AM, Benoit Cousson wrote: >> Hi, >> >> On 12/14/2012 07:44 PM, Paul Walmsley wrote: >>> Hi >>> >>> On Fri, 14 Dec 2012, Tony Lindgren wrote: >>> Paul, what about this patch? Looks like you've acked the other clock patches in this series but not this one? >>> >>> I commented on it briefly here: >>> >>> https://patchwork.kernel.org/patch/1838111/ >>> >>> Maybe Benoît could comment here, but it looks to me (based on a >>> superficial look at the hardware clock tree data) that these clock nodes >>> should exist. In an ideal world, we'd be able to get back to the >>> autogeneration of this clock data. >> >> I'm not sure to understand either the rational for that patch. What the >> point of merging the two nodes? >> I mean, we can do it, but AFAIR, we have always decided to use atomic >> node instead of big nodes that handle everything. >> > > I can see a similar thing done for mcbsp clocks (e.g. /* Merged > func_mcbsp1_gfclk into mcbsp1 */), mmc clocks, timer clocks, mcasp > clock, and sgx clock. i.e. The clock sel (mux) is combined with clock > gate. I don't see why USB host has to be done differently. Hehe, well, in fact USB is using the right approach, the others are the exceptions :-) It was done for legacy reason but should disappear once the modulemode will be be removed from the clock nodes. > Were exceptions made for the above clocks in the auto generation code? > > The problem from driver point of view is that it has to manage an > additional clock per port. Not a big deal, but I thought it could be > avoided. In theory, the driver should just managed the mux. The modulemode being managed already by hwmod. Regards, Benoit -- 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: Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
* they only forward requests from the root hub. Therefore
* controllers should always be enabled for remote wakeup.
*/
- device_wakeup_enable(hcd->self.controller);
+ if (!usb_hcd_wakeup_quirks(hcd->self.controller))
+ device_wakeup_enable(hcd->self.controller);
return retval;
error_create_attr_group:
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index fdefd9c..ba847d3 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -12,6 +12,7 @@
*/
#include
+#include
#include
#include "usb.h"
@@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
*udev)
quirks);
udev->quirks |= quirks;
}
+
+struct pci_hcd {
+ u32 vendor;
+ u32 device;
+};
+
+static struct pci_hcd hcd_wakeup_qrk[] = {
+ {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
+ {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
+ { }
+};
+
+int usb_hcd_wakeup_quirks(struct device *dev)
+{
+ struct pci_dev *pdev;
+ int i;
+
+ if (dev->bus != (struct bus_type *)&pci_bus_type)
+ return 0;
+
+ pdev = to_pci_dev(dev);
+ for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
+ if ((hcd_wakeup_qrk[i].vendor == pdev->vendor) &&
+ (hcd_wakeup_qrk[i].device == pdev->device)) {
+ return 1;
+ }
+
+ return 0;
+}
I would informing the user via dmesg output about the applied quirk
and a point him to relevant documentation. Something like this:
"Detected OHCI controller ID :, which requires no-wakeup quirk.
See Documentation/quirks/ohci-no-wakeup.txt"
--
Octavio.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2 v2] usb/core: update power budget for SuperSpeed
Sarah pointed out that the USB3.0 spec also updates the amount of power
that may be consumed by the device and quoted 9.2.5.1:
|"The amount of current draw for SuperSpeed devices are increased to 150
|mA for low-power devices and 900 mA for high-power"
This patch tries to update all users to use the larger values for
SuperSpeed devices and use the "old" ones for everything else.
While here, two other changes suggested by Alan:
- the comment referering to 7.2.1.1 has been updated to 7.2.1 which is
the correct source of the action.
- the check for hubs with zero ports has been removed.
- compute bus power via full_load * num_ports on root hubs
Signed-off-by: Sebastian Andrzej Siewior
---
v1..v2: compute bus power via "full_load * num_ports"
drivers/usb/core/hcd.c |1 -
drivers/usb/core/hub.c | 55 +++-
2 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 4225d5e..5f6da8b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2506,7 +2506,6 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
/* starting here, usbcore will pay attention to this root hub */
- rhdev->bus_mA = min(500u, hcd->power_budget);
if ((retval = register_root_hub(hcd)) != 0)
goto err_register_root_hub;
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4735425..4efc8cc 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1292,6 +1292,8 @@ static int hub_configure(struct usb_hub *hub,
unsigned int pipe;
int maxp, ret, i;
char *message = "out of memory";
+ unsigned unit_load;
+ unsigned full_load;
hub->buffer = kmalloc(sizeof(*hub->buffer), GFP_KERNEL);
if (!hub->buffer) {
@@ -1338,6 +1340,13 @@ static int hub_configure(struct usb_hub *hub,
}
wHubCharacteristics = le16_to_cpu(hub->descriptor->wHubCharacteristics);
+ if (hub_is_superspeed(hdev)) {
+ unit_load = 150;
+ full_load = 900;
+ } else {
+ unit_load = 100;
+ full_load = 500;
+ }
/* FIXME for USB 3.0, skip for now */
if ((wHubCharacteristics & HUB_CHAR_COMPOUND) &&
@@ -1458,32 +1467,36 @@ static int hub_configure(struct usb_hub *hub,
}
le16_to_cpus(&hubstatus);
if (hdev == hdev->bus->root_hub) {
- if (hdev->bus_mA == 0 || hdev->bus_mA >= 500)
- hub->mA_per_port = 500;
+ if (hcd->power_budget > 0)
+ hdev->bus_mA = hcd->power_budget;
+ else
+ hdev->bus_mA = full_load * hdev->maxchild;
+ if (hdev->bus_mA >= full_load)
+ hub->mA_per_port = full_load;
else {
hub->mA_per_port = hdev->bus_mA;
hub->limited_power = 1;
}
} else if ((hubstatus & (1 << USB_DEVICE_SELF_POWERED)) == 0) {
+ int remaining = hdev->bus_mA -
+ hub->descriptor->bHubContrCurrent;
+
dev_dbg(hub_dev, "hub controller current requirement: %dmA\n",
hub->descriptor->bHubContrCurrent);
hub->limited_power = 1;
- if (hdev->maxchild > 0) {
- int remaining = hdev->bus_mA -
- hub->descriptor->bHubContrCurrent;
- if (remaining < hdev->maxchild * 100)
- dev_warn(hub_dev,
+ if (remaining < hdev->maxchild * unit_load)
+ dev_warn(hub_dev,
"insufficient power available "
"to use all downstream ports\n");
- hub->mA_per_port = 100; /* 7.2.1.1 */
- }
+ hub->mA_per_port = unit_load; /* 7.2.1 */
+
} else {/* Self-powered external hub */
/* FIXME: What about battery-powered external hubs that
* provide less current per port? */
- hub->mA_per_port = 500;
+ hub->mA_per_port = full_load;
}
- if (hub->mA_per_port < 500)
+ if (hub->mA_per_port < full_load)
dev_dbg(hub_dev, "%umA bus power budget for each child\n",
hub->mA_per_port);
@@ -4145,16 +4158,23 @@ hub_power_remaining (struct usb_hub *hub)
for (port1 = 1; port1 <= hdev->maxchild; ++port1) {
struct usb_device *udev = hub->ports[port1 - 1]->child;
int delta;
+ unsignedunit_load;
if (!udev)
continue;
+ if (hub_is_superspeed(udev))
+ unit_load = 150;
+ else
+
[PATCH 1/2 v3] usb/core: consider link speed while looking at bMaxPower
The USB 2.0 specification says that bMaxPower is the maximum power
consumption expressed in 2 mA units and the USB 3.0 specification says
that it is expressed in 8 mA units.
This patch adds a helper function usb_get_max_power() which computes the
value based on config & usb_device's speed value. The sysfs interface &
the device descriptor dump compute the value on their own.
Cc: Sarah Sharp
Cc: Greg Kroah-Hartman
Signed-off-by: Sebastian Andrzej Siewior
---
v2..v3: use usb_get_max_power() in sysfs code.
drivers/usb/core/devices.c | 13 ++---
drivers/usb/core/generic.c |2 +-
drivers/usb/core/hub.c |2 +-
drivers/usb/core/message.c |2 +-
drivers/usb/core/sysfs.c | 31 ++-
drivers/usb/core/usb.h |9 +
6 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/core/devices.c b/drivers/usb/core/devices.c
index cbacea9..e33224e 100644
--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -316,17 +316,23 @@ static char *usb_dump_iad_descriptor(char *start, char
*end,
*/
static char *usb_dump_config_descriptor(char *start, char *end,
const struct usb_config_descriptor *desc,
- int active)
+ int active, int speed)
{
+ int mul;
+
if (start > end)
return start;
+ if (speed == USB_SPEED_SUPER)
+ mul = 8;
+ else
+ mul = 2;
start += sprintf(start, format_config,
/* mark active/actual/current cfg. */
active ? '*' : ' ',
desc->bNumInterfaces,
desc->bConfigurationValue,
desc->bmAttributes,
-desc->bMaxPower * 2);
+desc->bMaxPower * mul);
return start;
}
@@ -342,7 +348,8 @@ static char *usb_dump_config(int speed, char *start, char
*end,
if (!config)
/* getting these some in 2.3.7; none in 2.3.6 */
return start + sprintf(start, "(null Cfg. desc.)\n");
- start = usb_dump_config_descriptor(start, end, &config->desc, active);
+ start = usb_dump_config_descriptor(start, end, &config->desc, active,
+ speed);
for (i = 0; i < USB_MAXIADS; i++) {
if (config->intf_assoc[i] == NULL)
break;
diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
index eff2010..271e761 100644
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -100,7 +100,7 @@ int usb_choose_configuration(struct usb_device *udev)
*/
/* Rule out configs that draw too much bus current */
- if (c->desc.bMaxPower * 2 > udev->bus_mA) {
+ if (usb_get_max_power(udev, c) > udev->bus_mA) {
insufficient_power++;
continue;
}
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a815fd2..4735425 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4152,7 +4152,7 @@ hub_power_remaining (struct usb_hub *hub)
/* Unconfigured devices may not use more than 100mA,
* or 8mA for OTG ports */
if (udev->actconfig)
- delta = udev->actconfig->desc.bMaxPower * 2;
+ delta = usb_get_max_power(udev, udev->actconfig);
else if (port1 != udev->bus->otg_port || hdev->parent)
delta = 100;
else
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 131f736..444d30e 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1751,7 +1751,7 @@ int usb_set_configuration(struct usb_device *dev, int
configuration)
}
}
- i = dev->bus_mA - cp->desc.bMaxPower * 2;
+ i = dev->bus_mA - usb_get_max_power(dev, cp);
if (i < 0)
dev_warn(&dev->dev, "new config #%d exceeds power "
"limit by %dmA\n",
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index 818e4a0..3f81a3d 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -17,7 +17,7 @@
#include "usb.h"
/* Active configuration fields */
-#define usb_actconfig_show(field, multiplier, format_string) \
+#define usb_actconfig_show(field, format_string) \
static ssize_t show_##field(struct device *dev, \
struct device_attribute *attr, char *buf) \
{ \
@@ -28,18 +28,31 @@ static ssize_t show_##field(struct device *dev,
\
actconfig = udev->actconfig;
Re: [PATCH] usb: gadget zero: avoid unnecessary reinit of data in f_sourcesink
On 12/17/2012 04:45 PM, Sebastian Andrzej Siewior wrote: On Thu, Dec 13, 2012 at 03:11:19PM +0100, Armando Visconti wrote: In the IN case, since the USB request is allocated only when the source/sink function is started and never freed, the USB ept buffer needs to be inited only at the beginning. This change ^^ results into a more performant g_zero module, especially when 'pattern=1' is selected. Besides that the patch looks fine :) Do you mean that 'inited' should be changed with 'initialized'? Oh ... my poor english... :( Rgds, Arm -- 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: Device configuration fails on superspeed, succeeds on highspeed
On Mon, Dec 17, 2012 at 7:33 AM, Alan Stern wrote: > On Sun, 16 Dec 2012, Vincent Pelletier wrote: > >> Le dimanche 16 décembre 2012 20:46:38, Vincent Pelletier a écrit : >> > I checked the specs, and the warnings about wMaxPacketSize seem >> > justified (although it's unclear to me wether wMaxPacketSize is >> > restricted to exactly 512B in HS, or only upper-bound at 512B). >> >> Another reply to myself: >> Tested USB device uses a Cypress FX2LP: >> >> http://www.summitsoftconsulting.com/picts/iti_pcb_top.jpg >> >> I checked the FX2LP specs, and endpoint 1 in both directions is hardwired to >> wMaxPacketSize of 64. I believe the FX2LP is quite widespread (judging by the >> availability of a GPL toolchain for it and two CLI tools to send its >> firmware), so those warnings might cause redundant bug reports. > > It does seem odd that people would buy and use these chips even > though they are explicitly in violation of the USB specification. A > device containing one of these things could never pass the USB-CV > verification test. > > It may be possible for xhci-hcd to work around the bug (by internally > changing wMaxPacketSize to 512). > It does not need to be worked around. The fx2 docs specifically say ep1 cannot be used as a bulk endpoint in HS mode. Vincent, RTFM, Cypress has good, downloadable chip docs. Ep1 can either be a legal int/iso endpoint or just not used - all specified in the device/interface descriptors. Nothing in the USB spec requires all device endpoints to be used, or that interfaces have sequentially numbered endpoints. Regards, Steve -- 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: USB issue with kernel 3.6
Hi Alan, I applied the latest patch, changing the unlinking behavior of EHCI. I tested quite extensively and I could not see the issue (as expected). At a certain point I lost 3 HDDs, but this is something I saw before (it happens very seldom, maybe future debugging) and it was not really locking the EHCI driver. Another thing is that the read performance was around about 10% slower that the usual one. I saw 3700~3800 KB/sec per HDD, while, under normal conditions, I saw 4100~4200 KB/sec per HDD. I think that's all, how do you want to proceed now? Please note that shortly I'll not be anymore with my PC, until January, so we can take it easy. In this respect, I wish you Merry Christmas and Happy New Year. bye, pg On Mon, Dec 17, 2012 at 10:57:48AM -0500, Alan Stern wrote: > On Sun, 16 Dec 2012, Piergiorgio Sartor wrote: > > > Hi Alan, > > > > I applied the modifications you suggested, this is the output: > > > > [ 110.922009] ehci_hcd :00:0b.1: async off > > [ 209.362134] ehci_hcd :00:0b.1: async on > > [ 241.794760] ehci_hcd :00:0b.1: alan start cur time 4294908992 last > > scan 4294878606 > > [ 241.794774] ehci_hcd :00:0b.1: command 10035 cmd reg 10035 status > > reg e008 > > [ 241.794779] ehci_hcd :00:0b.1: async list: > > [ 241.794787] ehci_hcd :00:0b.1: qh 880149fe7800 hw > > 8800af80 dma af80 next 880146ce3f80 hw_next af800c62 > > [ 241.794795] ehci_hcd :00:0b.1: qh 880146ce3f80 hw > > 8800af800c60 dma af800c60 next 880146ce3780 hw_next af800d22 > > [ 241.794801] ehci_hcd :00:0b.1: qh 880146ce3780 hw > > 8800af800d20 dma af800d20 next 880147776680 hw_next af800ae2 > > [ 241.794808] ehci_hcd :00:0b.1: qh 880147776680 hw > > 8800af800ae0 dma af800ae0 next 8801478bf380 hw_next af800a22 > > [ 241.794815] ehci_hcd :00:0b.1: qh 8801478bf380 hw > > 8800af800a20 dma af800a20 next 88014070da00 hw_next af800f02 > > [ 241.794821] ehci_hcd :00:0b.1: qh 88014070da00 hw > > 8800af800f00 dma af800f00 next 8801407d3800 hw_next af800de2 > > [ 241.794828] ehci_hcd :00:0b.1: qh 8801407d3800 hw > > 8800af800de0 dma af800de0 next 8801478bfc80 hw_next af800782 > > [ 241.794834] ehci_hcd :00:0b.1: qh 8801478bfc80 hw > > 8800af800780 dma af800780 next 88014079e480 hw_next af800ba2 > > [ 241.794841] ehci_hcd :00:0b.1: qh 88014079e480 hw > > 8800af800ba0 dma af800ba0 next 8801478bf780 hw_next af8008a2 > > [ 241.794847] ehci_hcd :00:0b.1: qh 8801478bf780 hw > > 8800af8008a0 dma af8008a0 next 8801478bfd00 hw_next af800962 > > [ 241.794854] ehci_hcd :00:0b.1: qh 8801478bfd00 hw > > 8800af800960 dma af800960 next (null) hw_next af82 > > [ 241.794861] ehci_hcd :00:0b.1: This qh link time 4294878614 enqueue > > time 4294878614 td token 1f8c80 ov token 0 > > [ 241.794869] ehci_hcd :00:0b.1: qh 8801478bfd00 naf82 info > > 4200220e 4000 qtd af820540 > > [ 241.794876] ehci_hcd :00:0b.1: overlay td 8800af800970 naf820d80 > > 0001 t p0=af883a9f > > [ 241.794884] ehci_hcd :00:0b.1: dma af820d80 td 8800af820d80 > > naf820960 0001 t001f8c80 p0=af883a80 > > [ 241.794892] ehci_hcd :00:0b.1: dummy af820960 td 8800af820960 > > n0001 0001 t0040 p0= > > [ 241.805935] ehci_hcd :00:0b.1: giveback urb 8801455fa300 actual 0 > > [ 241.805943] ehci_hcd :00:0b.1: alan end > > This confirms it. The async schedule isn't running, even though it is > turned on and the status register says that it is running. > > > The first "async off" happened, I guess correctly, > > when the hot-plug settled and all the HDDs where > > in place as expected. > > The "async on" happened as soon as I started to > > read 10 HDDs in parallel, I think correctly too. > > > > After few seconds, this time without any "help", > > the problem appeared with the log as reported. > > > > I noticed several "async on/off" in dmesg, it > > seems to me all were consistent. > > This is all what one would expect in normal operation. > > It seems clear that we aren't going to be able to find the cause of > the bug. So let's try another approach: We'll change the commit you > identified as the one where the problems began. > > The patch below will prevent the driver from unlinking any idle QHs > from the async schedule. This is a little overboard, because even > before that commit they did get unlinked, one at a time. Still, let's > see if this prevents the problem. (You should apply this on top of the > other patches.) > > Alan Stern > > > > Index: usb-3.7/drivers/usb/host/ehci-q.c > === > --- usb-3.7.orig/drivers/usb/host/ehci-q.c > +++ usb-3.7/drivers/usb/host/ehci-q.c > @@ -1347,7 +1347,6 @@ static void scan_async (struct ehci_hcd >
Re: USB issue with kernel 3.6
On Mon, 17 Dec 2012, Piergiorgio Sartor wrote:
> Hi Alan,
>
> I applied the latest patch, changing the unlinking
> behavior of EHCI.
>
> I tested quite extensively and I could not see the
> issue (as expected). At a certain point I lost 3 HDDs,
> but this is something I saw before (it happens very
> seldom, maybe future debugging) and it was not really
> locking the EHCI driver.
>
> Another thing is that the read performance was around
> about 10% slower that the usual one.
> I saw 3700~3800 KB/sec per HDD, while, under normal
> conditions, I saw 4100~4200 KB/sec per HDD.
The slower performance might be caused by all the idle QHs remaining on
the async list. The controller has to look at them because they are on
the list, even though they aren't being used, and that could slow it
down.
> I think that's all, how do you want to proceed now?
Below is another patch, which is meant to replace the previous one.
This changes the behavior to be like the driver was before the
troublesome commit: Only one idle QH will be unlinked from the async
schedule at a time.
> Please note that shortly I'll not be anymore with
> my PC, until January, so we can take it easy.
>
> In this respect, I wish you Merry Christmas and
> Happy New Year.
Enjoy your holidays too.
Alan Stern
Index: usb-3.7/drivers/usb/host/ehci-q.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-q.c
+++ usb-3.7/drivers/usb/host/ehci-q.c
@@ -1279,8 +1279,9 @@ static void unlink_empty_async(struct eh
if (list_empty(&qh->qtd_list) &&
qh->qh_state == QH_STATE_LINKED) {
- if (!stopped && qh->unlink_cycle ==
- ehci->async_unlink_cycle)
+ if (!stopped && (qh->unlink_cycle ==
+ ehci->async_unlink_cycle ||
+ ehci->async_unlink))
check_unlinks_later = true;
else
single_unlink_async(ehci, qh);
--
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: Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
> On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu
> wrote:
>
> > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > index f034716..9335f1b 100644
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
> > * they only forward requests from the root hub. Therefore
> > * controllers should always be enabled for remote wakeup.
> > */
> > - device_wakeup_enable(hcd->self.controller);
> > + if (!usb_hcd_wakeup_quirks(hcd->self.controller))
> > + device_wakeup_enable(hcd->self.controller);
> > return retval;
> >
> > error_create_attr_group:
> > diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> > index fdefd9c..ba847d3 100644
> > --- a/drivers/usb/core/quirks.c
> > +++ b/drivers/usb/core/quirks.c
> > @@ -12,6 +12,7 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include "usb.h"
> >
> > @@ -226,3 +227,33 @@ void usb_detect_interface_quirks(struct usb_device
> > *udev)
> > quirks);
> > udev->quirks |= quirks;
> > }
> > +
> > +struct pci_hcd {
> > + u32 vendor;
> > + u32 device;
> > +};
> > +
> > +static struct pci_hcd hcd_wakeup_qrk[] = {
> > + {PCI_VENDOR_ID_NVIDIA, 0x026d}, /* MCP51 OHCI */
> > + {PCI_VENDOR_ID_NVIDIA, 0x0aa5}, /* MCP79 OHCI */
> > + {PCI_VENDOR_ID_NVIDIA, 0x0aa7}, /* MCP79 OHCI */
> > + { }
> > +};
> > +
> > +int usb_hcd_wakeup_quirks(struct device *dev)
> > +{
> > + struct pci_dev *pdev;
> > + int i;
> > +
> > + if (dev->bus != (struct bus_type *)&pci_bus_type)
> > + return 0;
> > +
> > + pdev = to_pci_dev(dev);
> > + for (i = 0; hcd_wakeup_qrk[i].vendor || hcd_wakeup_qrk[i].device; i++)
> > + if ((hcd_wakeup_qrk[i].vendor == pdev->vendor) &&
> > + (hcd_wakeup_qrk[i].device == pdev->device)) {
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
>
> I would informing the user via dmesg output about the applied quirk
> and a point him to relevant documentation. Something like this:
>
> "Detected OHCI controller ID :, which requires no-wakeup quirk.
> See Documentation/quirks/ohci-no-wakeup.txt"
Incidentally, this patch should be written differently. Instead of a
quirks routine, there should simply be a bad_wakeup bitflag added to
the usb_hcd structure. The flag should be set in ohci-pci.c by
matching against nVidia's PCI vendor ID.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v3] usb/core: consider link speed while looking at bMaxPower
On Mon, 17 Dec 2012, Sebastian Andrzej Siewior wrote: > The USB 2.0 specification says that bMaxPower is the maximum power > consumption expressed in 2 mA units and the USB 3.0 specification says > that it is expressed in 8 mA units. > This patch adds a helper function usb_get_max_power() which computes the > value based on config & usb_device's speed value. The sysfs interface & > the device descriptor dump compute the value on their own. > > Cc: Sarah Sharp > Cc: Greg Kroah-Hartman > Signed-off-by: Sebastian Andrzej Siewior > --- > v2..v3: use usb_get_max_power() in sysfs code. (but the patch description wasn't updated along with the code) Acked-by: 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/2 v2] usb/core: update power budget for SuperSpeed
On Mon, 17 Dec 2012, Sebastian Andrzej Siewior wrote: > Sarah pointed out that the USB3.0 spec also updates the amount of power > that may be consumed by the device and quoted 9.2.5.1: > > |"The amount of current draw for SuperSpeed devices are increased to 150 > |mA for low-power devices and 900 mA for high-power" > > This patch tries to update all users to use the larger values for > SuperSpeed devices and use the "old" ones for everything else. > > While here, two other changes suggested by Alan: > - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is > the correct source of the action. > - the check for hubs with zero ports has been removed. > - compute bus power via full_load * num_ports on root hubs > > Signed-off-by: Sebastian Andrzej Siewior > --- > v1..v2: compute bus power via "full_load * num_ports" Acked-by: 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 v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
On Mon, 17 Dec 2012, Benoit Cousson wrote: > It was done for legacy reason but should disappear once the modulemode > will be be removed from the clock nodes. Here's a start at taking care of the low-hanging fruit: http://marc.info/?l=linux-omap&m=135577685007813&w=2 Only lightly tested, so tests with Kconfigs with lots of OMAP drivers enabled would be appreciated. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On 12/13/2012 11:59 PM, Venu Byravarasu wrote: > As Tegra USB host driver is using instance number for resetting > PORT0 twice, adding a new DT property for handling this. Alan, Greg, Felip,e This series looks fine to me. I'd like to take all the Tegra-related USB patches through the Tegra tree for 3.9 if possible (so I'm looking for your acks here). I believe Venu plans to significantly clean up the EHCI/PHY driver split for Tegra, rework the drivers, and add support for Tegra30 in addition to Tegra20. Some of this requires changes to some Tegra board files and device trees to maintain "git bisect" I don't know for sure yet, but I believe that rework may also end up conflicting with other clock-related rework that will show up for Tegra in 3.9. Are you OK with this? I'll certainly look for your review/acks on the patches before picking them up though. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v2] usb/core: update power budget for SuperSpeed
On Mon, Dec 17, 2012 at 03:12:14PM -0500, Alan Stern wrote: > On Mon, 17 Dec 2012, Sebastian Andrzej Siewior wrote: > > > Sarah pointed out that the USB3.0 spec also updates the amount of power > > that may be consumed by the device and quoted 9.2.5.1: > > > > |"The amount of current draw for SuperSpeed devices are increased to 150 > > |mA for low-power devices and 900 mA for high-power" > > > > This patch tries to update all users to use the larger values for > > SuperSpeed devices and use the "old" ones for everything else. > > > > While here, two other changes suggested by Alan: > > - the comment referering to 7.2.1.1 has been updated to 7.2.1 which is > > the correct source of the action. > > - the check for hubs with zero ports has been removed. > > - compute bus power via full_load * num_ports on root hubs > > > > Signed-off-by: Sebastian Andrzej Siewior > > --- > > v1..v2: compute bus power via "full_load * num_ports" > > Acked-by: Alan Stern Acked-by: Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, Dec 17, 2012 at 02:07:59PM -0700, Stephen Warren wrote: > On 12/13/2012 11:59 PM, Venu Byravarasu wrote: > > As Tegra USB host driver is using instance number for resetting > > PORT0 twice, adding a new DT property for handling this. > > Alan, Greg, Felip,e > > This series looks fine to me. > > I'd like to take all the Tegra-related USB patches through the Tegra > tree for 3.9 if possible (so I'm looking for your acks here). I believe > Venu plans to significantly clean up the EHCI/PHY driver split for > Tegra, rework the drivers, and add support for Tegra30 in addition to > Tegra20. Some of this requires changes to some Tegra board files and > device trees to maintain "git bisect" I don't know for sure yet, but I > believe that rework may also end up conflicting with other clock-related > rework that will show up for Tegra in 3.9. Are you OK with this? I'll > certainly look for your review/acks on the patches before picking them > up though. You can't pick anything up for 3.9 until after 3.8-rc1 is out, according to the rules of linux-next, so please wait until that kernel is out before doing anything. Given the timing of 3.8-rc1, and my current vacation schedule, I'm not going to be able to do _any_ code review for the rest of the year, sorry. After that, I'll be glad to review 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
[PATCH] usb_8dev: add LED trigger support
Add support for canbus activity led indicators on usb_8dev devices by
calling appropriate can_led functions.
These are only enabled when CONFIG_CAN_LEDS is Y, becomes no-op
otherwise.
Signed-off-by: Bernd Krumboeck
---
drivers/net/can/usb/usb_8dev.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/can/usb/usb_8dev.c b/drivers/net/can/usb/usb_8dev.c
index 660b4f87..adec0d2 100644
--- a/drivers/net/can/usb/usb_8dev.c
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/* driver constants */
#define MAX_RX_URBS10
@@ -504,6 +505,8 @@ static void usb_8dev_rx_can_msg(struct usb_8dev_priv *priv,
stats->rx_packets++;
stats->rx_bytes += cf->can_dlc;
+
+ can_led_event(priv->netdev, CAN_LED_EVENT_RX);
} else {
netdev_warn(priv->netdev, "frame type %d unknown",
msg->type);
@@ -606,6 +609,8 @@ static void usb_8dev_write_bulk_callback(struct urb *urb)
can_get_echo_skb(netdev, context->echo_index);
+ can_led_event(netdev, CAN_LED_EVENT_TX);
+
/* Release context */
context->echo_index = MAX_TX_URBS;
@@ -830,6 +835,8 @@ static int usb_8dev_open(struct net_device *netdev)
if (err)
return err;
+ can_led_event(netdev, CAN_LED_EVENT_OPEN);
+
/* finally start device */
err = usb_8dev_start(priv);
if (err) {
@@ -882,6 +889,8 @@ static int usb_8dev_close(struct net_device *netdev)
close_candev(netdev);
+ can_led_event(netdev, CAN_LED_EVENT_STOP);
+
return err;
}
@@ -990,6 +999,8 @@ static int usb_8dev_probe(struct usb_interface *intf,
(version>>8) & 0xff, version & 0xff);
}
+ devm_can_led_init(netdev);
+
return 0;
cleanup_cmd_msg_buffer:
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xHCI immediately wakes up Asus P8Z68-V LX in S5
On Sun, Dec 16, 2012 at 12:37:00AM +, Ben Hutchings wrote: > Since Linux 3.2.16, my desktop with an Asus P8Z68-V LX motherboard > always wakes up a few seconds after I shutdown. I then have to switch > it off a second time. This still occurs in Linux 3.6.9 (haven't tried > 3.7 yet). > > I initially bisected this to: > > commit 13a307e1a4a10502d688ce058141bc503933214e > Author: Lin Ming > Date: Mon Nov 28 09:46:02 2011 +0800 > > ACPICA: Fix to allow region arguments to reference other scopes > > commit 8931d9ea78848b073bf299594f148b83abde4a5e upstream. > > However, that seems to be a perfectly good bug fix (the error mentioned > in the commit message did previously appear on this system). I > therefore tried cherry-picking it onto earlier versions, and bisected > to: > > commit 9777e3ce907d4cb5a513902a87ecd03b52499569 > Author: Andiry Xu > Date: Thu Oct 14 07:23:03 2010 -0700 > > USB: xHCI: bus power management implementation Hmm. So if we enable PCI bus suspend for this xHCI host controller, then it will immediately wakeup the system on shutdown? What happens when runtime PM is enabled for the host (and any USB devices attached to it)? Does the host controller stay in D3hot, or does it immediately pop back into D0? Can you turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG for your kernel and send me the dmesg? I'm wondering if the xHCI host controller is either failing to complete the host suspend command, or perhaps failing to be halted. > That is, this is the first commit for which cherry-picking commit > 13a307e1a4a1 on top results in the problem. > > lspci -vvnn says: > > 04:00.0 USB Controller [0c03]: Device [1b21:1042] (prog-if 30) > Subsystem: ASUSTeK Computer Inc. Device [1043:8488] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at fe50 (64-bit, non-prefetchable) [size=32K] > Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+ > Address: Data: > Capabilities: [68] MSI-X: Enable+ Count=8 Masked- > Vector table: BAR=0 offset=2000 > PBA: BAR=0 offset=2080 > Capabilities: [78] Power Management version 3 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA > PME(D0-,D1-,D2-,D3hot+,D3cold+) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [80] Express (v2) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, > L1 <2us > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- > Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 128 bytes, MaxReadReq 512 bytes > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- > TransPend- > LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 > unlimited, L1 unlimited > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- > BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis- > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, > Selectable De-emphasis: -6dB >Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- >Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB > Capabilities: [100 v1] Virtual Channel > Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 > Arb:Fixed- WRR32- WRR64- WRR128- > Ctrl: ArbSelect=Fixed > Status: InProgress- > VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- > Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- > Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 > Status: NegoPending- InProgress- > Kernel driver in use: xhci_hcd > > No devices are connected to the xHCI. > > 'echo disabled > /sys/bus/pci/devices/:04:00.0/power/wakeup' does > *not* work around this. Does unloading the xHCI driver before shutdown fix this? > I can try updating the BIOS if you think this might help (the > description of changes is very vague). Let's see what the dmesg shows before you update the BIOS. But in general, if it's an
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, 17 Dec 2012, Stephen Warren wrote: > On 12/13/2012 11:59 PM, Venu Byravarasu wrote: > > As Tegra USB host driver is using instance number for resetting > > PORT0 twice, adding a new DT property for handling this. > > Alan, Greg, Felip,e > > This series looks fine to me. > > I'd like to take all the Tegra-related USB patches through the Tegra > tree for 3.9 if possible (so I'm looking for your acks here). I believe > Venu plans to significantly clean up the EHCI/PHY driver split for > Tegra, rework the drivers, and add support for Tegra30 in addition to > Tegra20. Some of this requires changes to some Tegra board files and > device trees to maintain "git bisect" I don't know for sure yet, but I > believe that rework may also end up conflicting with other clock-related > rework that will show up for Tegra in 3.9. Are you OK with this? I'll > certainly look for your review/acks on the patches before picking them > up though. Regarding the changes to drivers/usb/host/ehci-tegra.c: Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: tegra: Add new DT property to USB node.
On Mon, 17 Dec 2012, Greg KH wrote: > You can't pick anything up for 3.9 until after 3.8-rc1 is out, according > to the rules of linux-next Well, you can accept a submission and store it in a private tree until then. You just can't put it in any tree that feeds into linux-next. 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: Device configuration fails on superspeed, succeeds on highspeed
On Sun, Dec 16, 2012 at 04:49:42PM -0500, Alan Stern wrote: > On Sun, 16 Dec 2012, Vincent Pelletier wrote: > > > Hi. > > > > I have a device which enumerates properly on this superspeed host controler: > > > > 06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host > > Controller (rev 01) > > > > but triggers several warnings from the xhci_hcd module, and ultimately fails > > activating the default configuration: > > > > usb 1-1: new high-speed USB device number 6 using xhci_hcd > > usb 1-1: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid > > maxpacket 64 > > usb 1-1: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid > > maxpacket 64 > > usb 1-1: New USB device found, idVendor=16c0, idProduct=07a9 > > usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > > usb 1-1: Product: USB Analyzer 1480A It's ironic that a USB bus analyzer doesn't follow the USB 2.0 specification... > > usb 1-1: Manufacturer: International Test Instruments > > usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 > > microframes > > usb 1-1: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 > > microframes > > usb 1-1: ep 0x82 - rounding interval to 32768 microframes, ep desc says 0 > > microframes > > usb 1-1: ep 0x4 - rounding interval to 32768 microframes, ep desc says 0 > > microframes > > usb 1-1: ep 0x86 - rounding interval to 32768 microframes, ep desc says 0 > > microframes > > usb 1-1: ep 0x88 - rounding interval to 32768 microframes, ep desc says 0 > > microframes > > xhci_hcd :02:00.0: ERROR: unexpected command completion code 0x11. > > usb 1-1: can't set config #1, error -22 > > > > So at this point, this device is unusable with xhci_hcd. > > > > I checked the specs, and the warnings about wMaxPacketSize seem > > justified (although it's unclear to me wether wMaxPacketSize is > > restricted to exactly 512B in HS, or only upper-bound at 512B). > > It's supposed to be exactly 512 bytes. > > > I'm less > > sure about the bInterval ones, 0 is specified as a possible value > > (reading the 2.0 specs, that is). > > Those messages are a bug. xhci_get_endpoint_interval() includes a > comment about 0 being a valid bInterval value, but the code fails to > take it into account. Thanks for catching that, Alan. I'll send a patch for Vincent to test shortly. > > As for the final 0x11 (aka COMP_EINVAL), > > I don't know what the cause is. > > My guess is that it is caused by the invalid wMaxPacketSize values. > But that's just a guess. The 0x11 return value means the xHCI host controller didn't like the endpoint context values that the xHCI driver filled in. It could be caused by the wMaxPacketSize value, or perhaps we're overwriting other bits of the endpoint context by setting the interval to a very large value. Alan, what does the EHCI scheduler do if the HS device's wMaxPacketSize is set to 64 bytes? Happily schedule 64 byte transfers? Or will it schedule 512 byte packets since that's the only allowed type for HS bulk endpoints? I can unconditionally set the HS bulk wMaxPacketSize to 512 bytes, but I'm not sure that will work with this device. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: Handle HS bulk/ctrl endpoints that don't NAK.
A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK. If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).
The xHCI code to compute the NAK interval does handle the special case
of zero properly. The current code unconditionally subtracts one from
bInterval and uses it as an exponent. This causes a very large
bInterval to be used, and warning messages like these will be printed:
usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0
microframes
This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.
This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".
Reported-by: Vincent Pelletier
Suggested-by: Alan Stern
Signed-off-by: Sarah Sharp
Cc: sta...@kernel.org
---
Hi Vincent,
Will you please apply this patch to whatever stable kernel you're
running and see if the device works under xHCI? Please send the dmesg
output in either case.
If you need directions for applying the patch and compiling your kernel,
please see: http://kernelnewbies.org/KernelBuild
Sarah Sharp
drivers/usb/host/xhci-mem.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index fb51c70..35616ff 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1250,6 +1250,8 @@ static unsigned int xhci_microframes_to_exponent(struct
usb_device *udev,
static unsigned int xhci_parse_microframe_interval(struct usb_device *udev,
struct usb_host_endpoint *ep)
{
+ if (ep->desc.bInterval == 0)
+ return 0;
return xhci_microframes_to_exponent(udev, ep,
ep->desc.bInterval, 0, 15);
}
--
1.7.9
--
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: Device configuration fails on superspeed, succeeds on highspeed
On Mon, Dec 17, 2012 at 11:08 AM, Steve Calfee wrote: > On Mon, Dec 17, 2012 at 7:33 AM, Alan Stern wrote: >> On Sun, 16 Dec 2012, Vincent Pelletier wrote: >> >>> Le dimanche 16 décembre 2012 20:46:38, Vincent Pelletier a écrit : >>> > I checked the specs, and the warnings about wMaxPacketSize seem >>> > justified (although it's unclear to me wether wMaxPacketSize is >>> > restricted to exactly 512B in HS, or only upper-bound at 512B). >>> >>> Another reply to myself: >>> Tested USB device uses a Cypress FX2LP: >>> >>> http://www.summitsoftconsulting.com/picts/iti_pcb_top.jpg >>> >>> I checked the FX2LP specs, and endpoint 1 in both directions is hardwired to >>> wMaxPacketSize of 64. I believe the FX2LP is quite widespread (judging by >>> the >>> availability of a GPL toolchain for it and two CLI tools to send its >>> firmware), so those warnings might cause redundant bug reports. >> >> It does seem odd that people would buy and use these chips even >> though they are explicitly in violation of the USB specification. A >> device containing one of these things could never pass the USB-CV >> verification test. >> >> It may be possible for xhci-hcd to work around the bug (by internally >> changing wMaxPacketSize to 512). >> > > It does not need to be worked around. The fx2 docs specifically say > ep1 cannot be used as a bulk endpoint in HS mode. Vincent, RTFM, > Cypress has good, downloadable chip docs. Ep1 can either be a legal > int/iso endpoint or just not used - all specified in the > device/interface descriptors. Nothing in the USB spec requires all > device endpoints to be used, or that interfaces have sequentially > numbered endpoints. > > Regards, Steve Hi, Vincent, After reading the first message in the thread I realized that you are not writing the fx2 device, but are trying to use a device you purchased. Sorry. The fx2 is not at fault, the device has a bad, invalid endpoint descriptor for ep1. I doubt if they are using the ep, just defining it. Perhaps you could contact the manufacturer? Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: host: xhci: remove unused trb var in xhci_irq()
Hi Javier,
Thanks for catching this! The patch is going to have to wait until
after the 3.8 merge window closes, since I believe Greg isn't accepting
usb-next pull requests yet.
Sarah Sharp
On Sun, Dec 16, 2012 at 04:21:31AM +0100, Javier Martinez Canillas wrote:
> The union xhci_trb *trb variable is defined and assigned
> inside the xHCI IRQ handler function but is never used.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/usb/host/xhci-ring.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index cbb44b7..b1b6abb 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -2697,13 +2697,11 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
> {
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> u32 status;
> - union xhci_trb *trb;
> u64 temp_64;
> union xhci_trb *event_ring_deq;
> dma_addr_t deq;
>
> spin_lock(&xhci->lock);
> - trb = xhci->event_ring->dequeue;
> /* Check if the xHC generated the interrupt, or the irq is shared */
> status = xhci_readl(xhci, &xhci->op_regs->status);
> if (status == 0x)
> --
> 1.7.7.6
>
--
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: [Suggestion] drivers/usb/host/ohci* : not setting urb->hcpriv = NULL after kfree it.
于 2012年12月17日 23:27, Alan Stern 写道: > On Mon, 17 Dec 2012, Chen Gang wrote: > >> 于 2012年12月17日 11:08, Alan Stern 写道: >>> It is pretty much as I explained in my previous email. >>> >>> finish_urb calls usb_free_priv while holding the lock. Then while >>> still holding the lock, it calls usb_hcd_unlink_urb_from_ep. >>> >>> In addition, ohci_urb_dequeue calls usb_hcd_check_unlink_urb while >>> holding the lock, and does nothing if the return value is nonzero. >>> >>> So all you need to do is verify that after usb_hcd_unlink_urb_from_ep >>> runs, usb_hcd_check_unlink_urb will always return a nonzero value. In >>> fact, it will return -EIDRM -- until the next time the URB is submitted >>> and usb_hcd_link_urb_to_ep is called. >> >> it is true for ohci_urb_dequeue. >> how about finish_unlinks and takeback_td in drives/usb/host/ohci-q.c ? >> (they also can call finish_urb). > > Those routines, like almost all the rest of the driver, look at TDs > that haven't been processed yet and URBs that haven't been completed > yet. Once a TD is processed, it is freed. Since finish_urb isn't > called until all the TDs in an URB have been processed, urb->hcpriv > will be a valid pointer for any URB encountered. > > The only places where this isn't true is while an URB is being > submitted. The submission routines are careful to free all the private > data structures if the URB is not accepted. > > Alan Stern > thank you for your reply in details. :-) next: I will write the 2 patches one for current suggestion. the other for sprintf suggestion. time region: tomorrow, I begin constructing relative environments. I should try to finish 2 patches within this week (before Mon Dec 24 2012) excuse me: I can not give a full test, but I need provide enough unit test, at least. after finish 2 patches, I will turn back for the details of your reply, again. welcome any additional suggestions thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.7 kernel hangs when doing scp
On Tue, Dec 18, 2012 at 12:01:35AM -0200, Fabio Estevam wrote: > Hi, > > Booting a 3.7 kernel on a mx6qsabrelite board via NFS and using an > asix USB/Ethernet adapter and then I try to transfer a 10MB file from > the target to the host: Has this ever worked before on any older kernel? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
From: fangxiaozhi
1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.
Signed-off-by: fangxiaozhi
diff -uprN linux-3.7_bak/drivers/usb/storage/usb.c
linux-3.7/drivers/usb/storage/usb.c
--- linux-3.7_bak/drivers/usb/storage/usb.c 2012-12-11 09:56:11.0
+0800
+++ linux-3.7/drivers/usb/storage/usb.c 2012-12-12 11:46:06.0 +0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, "supplemental l
.useTransport = use_transport, \
}
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name,\
+ .useProtocol = use_protocol,\
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}
+
static struct us_unusual_dev us_unusual_dev_list[] = {
# include "unusual_devs.h"
{ } /* Terminating entry */
@@ -131,6 +142,7 @@ static struct us_unusual_dev for_dynamic
#undef UNUSUAL_DEV
#undef COMPLIANT_DEV
#undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
#ifdef CONFIG_LOCKDEP
diff -uprN linux-3.7_bak/drivers/usb/storage/usual-tables.c
linux-3.7/drivers/usb/storage/usual-tables.c
--- linux-3.7_bak/drivers/usb/storage/usual-tables.c2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/usual-tables.c2012-12-13
20:51:27.0 +0800
@@ -41,6 +41,19 @@
#define USUAL_DEV(useProto, useTrans) \
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans) }
+/* Define the device is matched with Vendor ID and interface descriptors */
+#define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+ vendorName, productName, useProtocol, useTransport, \
+ initFunction, flags) \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor= (id_vendor), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr), \
+ .driver_info = (flags) }
+
struct usb_device_id usb_storage_usb_ids[] = {
# include "unusual_devs.h"
{ } /* Terminating entry */
@@ -50,6 +63,7 @@ MODULE_DEVICE_TABLE(usb, usb_storage_usb
#undef UNUSUAL_DEV
#undef COMPLIANT_DEV
#undef USUAL_DEV
+#undef UNUSUAL_VENDOR_INTF
/*
* The table of devices to ignore
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
From: fangxiaozhi
1. Optimize the match rules with new macro for Huawei USB storage devices,
to avoid to load USB storage driver for the modem interface
with Huawei devices.
2. Add to support new switch command for new Huawei USB dongles.
Signed-off-by: fangxiaozhi
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c2012-12-17
11:12:12.0 +0800
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_dat
return 0;
}
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us)
+/* This places the HUAWEI usb dongles in multi-port mode */
+static int usb_stor_huawei_feature_init(struct us_data *us)
{
int result;
@@ -104,3 +104,59 @@ int usb_stor_huawei_e220_init(struct us_
US_DEBUGP("Huawei mode set result is %d\n", result);
return 0;
}
+
+/* Find the supported Huawei USB dongles */
+static int usb_stor_huawei_dongles_pid(struct us_data *us)
+{
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+
+ idesc = &us->pusb_intf->cur_altsetting->desc;
+ idProduct = us->pusb_dev->descriptor.idProduct;
+ if (idesc && idesc->bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001)
+ || (idProduct == 0x1003)
+ || (idProduct == 0x1004)
+ || (idProduct >= 0x1401 && idProduct < 0x1501)
+ || (idProduct > 0x1504 && idProduct <= 0x1600)
+ || (idProduct >= 0x1c02 && idProduct <= 0x2202)) {
+ return 1;
+ }
+ }
+ return 0;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us)
+{
+ int result = 0;
+ int act_len = 0;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us->iobuf;
+
+ memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
+ bcbw->Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw->Tag = 0;
+ bcbw->DataTransferLength = 0;
+ bcbw->Flags = bcbw->Lun = 0;
+ bcbw->Length = sizeof(rewind_cmd);
+ memcpy(bcbw->CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us->send_bulk_pipe, &bcbw,
+ US_BULK_CS_WRAP_LEN, &act_len);
+ US_DEBUGP("transfer actual length=%d, result=%d\n", act_len, result);
+ return result;
+}
+
+int usb_stor_huawei_init(struct us_data *us)
+{
+ int result = 0;
+
+ if (usb_stor_huawei_dongles_pid(us)) {
+ if (us->pusb_dev->descriptor.idProduct >= 0x1446)
+ result = usb_stor_huawei_scsi_init(us);
+ else
+ result = usb_stor_huawei_feature_init(us);
+ }
+ return result;
+}
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.h
linux-3.7/drivers/usb/storage/initializers.h
--- linux-3.7_bak/drivers/usb/storage/initializers.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.h2012-12-17
10:39:55.0 +0800
@@ -46,5 +46,5 @@ int usb_stor_euscsi_init(struct us_data
* flash reader */
int usb_stor_ucr61s2b_init(struct us_data *us);
-/* This places the HUAWEI E220 devices in multi-port mode */
-int usb_stor_huawei_e220_init(struct us_data *us);
+/* This places the HUAWEI usb dongles in multi-port mode */
+int usb_stor_huawei_init(struct us_data *us);
Binary files linux-3.7_bak/drivers/usb/storage/initializers.o and
linux-3.7/drivers/usb/storage/initializers.o differ
diff -uprN linux-3.7_bak/drivers/usb/storage/unusual_devs.h
linux-3.7/drivers/usb/storage/unusual_devs.h
--- linux-3.7_bak/drivers/usb/storage/unusual_devs.h2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/unusual_devs.h2012-12-17
10:40:10.0 +0800
@@ -1527,335 +1527,10 @@ UNUSUAL_DEV( 0x1210, 0x0003, 0x0100, 0x
/* Reported by fangxiaozhi
* This brings the HUAWEI data card devices into multi-port mode
*/
-UNUSUAL_DEV( 0x12d1, 0x1001, 0x, 0x,
+UNUSUAL_VENDOR_INTF(0x12d1, 0x08, 0x06, 0x50,
"HUAWEI MOBILE",
"Mass Storage",
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
- 0),
-UNUSUAL_DEV( 0x12d1, 0x1003, 0x, 0x,
- "HUAWEI MOBILE",
- "Mass Storage",
- USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_huawei_e220_init,
- 0),
-UNUSUAL_DEV( 0x12d1, 0x1004, 0x, 0x,
- "HUAWEI MOBILE",
- "Mass Storage",
Re: [Suggestion] drivers/usb/host/ohci* : not setting urb->hcpriv = NULL after kfree it.
于 2012年12月17日 23:27, Alan Stern 写道: > On Mon, 17 Dec 2012, Chen Gang wrote: > >> 于 2012年12月17日 11:08, Alan Stern 写道: >>> It is pretty much as I explained in my previous email. >>> >>> finish_urb calls usb_free_priv while holding the lock. Then while >>> still holding the lock, it calls usb_hcd_unlink_urb_from_ep. >>> >>> In addition, ohci_urb_dequeue calls usb_hcd_check_unlink_urb while >>> holding the lock, and does nothing if the return value is nonzero. >>> >>> So all you need to do is verify that after usb_hcd_unlink_urb_from_ep >>> runs, usb_hcd_check_unlink_urb will always return a nonzero value. In >>> fact, it will return -EIDRM -- until the next time the URB is submitted >>> and usb_hcd_link_urb_to_ep is called. >> >> it is true for ohci_urb_dequeue. >> how about finish_unlinks and takeback_td in drives/usb/host/ohci-q.c ? >> (they also can call finish_urb). > > Those routines, like almost all the rest of the driver, look at TDs > that haven't been processed yet and URBs that haven't been completed > yet. Once a TD is processed, it is freed. Since finish_urb isn't > called until all the TDs in an URB have been processed, urb->hcpriv > will be a valid pointer for any URB encountered. > > The only places where this isn't true is while an URB is being > submitted. The submission routines are careful to free all the private > data structures if the URB is not accepted. > > Alan Stern > thank you for your reply in details. :-) next: I will write the 2 patches one for current suggestion. the other for sprintf suggestion. time region: tomorrow, I begin constructing relative environments. I should try to finish 2 patches within this week (before Mon Dec 24 2012) excuse me: I can not give a full test, but I need provide enough unit test, at least. after finish 2 patches, I will turn back for the details of your reply, again. welcome any additional suggestions thanks. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: Xbox 360 controller LEDs won't stop blinking
When I connect a wired Xbox 360 controller (black, in case it matters), the four LEDs around the "X" button start blinking and never stop. The controller is a retail "Xbox 360 Controller for Windows" device. dmesg: usb 2-1.1: new full-speed USB device number 3 using ehci_hcd input: Microsoft X-Box 360 pad as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input5 The gamepad does work (jstest shows the controls being pressed) and applications pick it up just fine. The problem is with the LEDs. I'm using kernel 3.7.1 (x86-64). The issue was there with previous kernels too. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: samsung: Add support to set pmu isolation
Adding support to parse device node data in order to get
required properties to set pmu isolation for usb-phy.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/usb/samsung-usbphy.txt | 10 +++
drivers/usb/phy/samsung-usbphy.c | 80 ++--
2 files changed, 82 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..112eaa6 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,13 @@ Required properties:
- compatible : should be "samsung,exynos4210-usbphy"
- reg : base physical address of the phy registers and length of memory mapped
region.
+- samsung,usb-phyctrl : should point to usb-phyctrl sub-node which provides
+ binding data to enable/disable device PHY handled by
+ PMU register.
+
+ Required properties:
+ - compatible : should be "samsung,usbdev-phyctrl" for
+ DEVICE type phy.
+ - samsung,phyctrl-reg: base physical address of
+ PHY_CONTROL register in PMU.
+- samsung,enable-mask : should be '1'
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..ef394c3 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -72,6 +72,8 @@ enum samsung_cpu_type {
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
* @regs: usb phy register memory base
+ * @devctrl_reg: usb phy-control pmu register memory base
+ * @en_mask: enable mask
* @ref_clk_freq: reference clock frequency selection
* @cpu_type: machine identifier
*/
@@ -81,12 +83,62 @@ struct samsung_usbphy {
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*devctrl_reg;
+ u32 en_mask;
int ref_clk_freq;
int cpu_type;
};
#define phy_to_sphy(x) container_of((x), struct samsung_usbphy, phy)
+static int samsung_usbphy_parse_dt_param(struct samsung_usbphy *sphy)
+{
+ struct device_node *usb_phyctrl;
+ u32 reg;
+
+ if (!sphy->dev->of_node) {
+ sphy->devctrl_reg = NULL;
+ return -ENODEV;
+ }
+
+ usb_phyctrl = of_parse_phandle(sphy->dev->of_node,
+ "samsung,usb-phyctrl", 0);
+ if (!usb_phyctrl) {
+ dev_dbg(sphy->dev, "Can't get usb-phy control node\n");
+ sphy->devctrl_reg = NULL;
+ return -ENODEV;
+ }
+
+ of_property_read_u32(usb_phyctrl, "samsung,phyctrl-reg", ®);
+
+ sphy->devctrl_reg = ioremap(reg, SZ_4);
+
+ of_property_read_u32(sphy->dev->of_node, "samsung,enable-mask",
+ &sphy->en_mask);
+
+ return 0;
+}
+
+/*
+ * Set isolation here for phy.
+ * SOCs control this by controlling corresponding PMU registers
+ */
+static void samsung_usbphy_set_isolation(struct samsung_usbphy *sphy, int on)
+{
+ void __iomem *usb_phyctrl_reg;
+ u32 en_mask = sphy->en_mask;
+ u32 reg;
+
+ usb_phyctrl_reg = sphy->devctrl_reg;
+
+ reg = readl(usb_phyctrl_reg);
+
+ if (on)
+ writel(reg & ~en_mask, usb_phyctrl_reg);
+ else
+ writel(reg | en_mask, usb_phyctrl_reg);
+}
+
/*
* Returns reference clock frequency selection value
*/
@@ -199,6 +251,8 @@ static int samsung_usbphy_init(struct usb_phy *phy)
/* Disable phy isolation */
if (sphy->plat && sphy->plat->pmu_isolation)
sphy->plat->pmu_isolation(false);
+ else
+ samsung_usbphy_set_isolation(sphy, false);
/* Initialize usb phy registers */
samsung_usbphy_enable(sphy);
@@ -228,6 +282,8 @@ static void samsung_usbphy_shutdown(struct usb_phy *phy)
/* Enable phy isolation */
if (sphy->plat && sphy->plat->pmu_isolation)
sphy->plat->pmu_isolation(true);
+ else
+ samsung_usbphy_set_isolation(sphy, true);
clk_disable_unprepare(sphy->clk);
}
@@ -249,17 +305,12 @@ static inline int samsung_usbphy_get_driver_data(struct
platform_device *pdev)
static int __devinit samsung_usbphy_probe(struct platform_device *pdev)
{
struct samsung_usbphy *sphy;
- struct samsung_usbphy_data *pdata;
+ struct samsung_usbphy_data *pdata = pdev->dev.platform_data;
struct device *dev = &pdev->dev;
struct resource *phy_mem;
void __iomem*phy_base;
struct clk *clk;
-
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "%s: no platform data defin
[PATCH] usb: phy: samsung: Add support to set pmu isolation
Based on patches for samsung-usbphy driver available at: https://patchwork.kernel.org/patch/1794651/ In this patch we are adding support to parse device tree data for samsung-usbphy driver and further setting pmu_isolation to enable/disable phy as and when needed. This further chucks out the need of platform data for samsung-usbphy on DT enabled system and hence serves the purpose of the discussion in the thread for: [PATCH v8 2/2] usb: s3c-hsotg: Adding phy driver support Vivek Gautam (1): usb: phy: samsung: Add support to set pmu isolation .../devicetree/bindings/usb/samsung-usbphy.txt | 10 +++ drivers/usb/phy/samsung-usbphy.c | 80 ++-- 2 files changed, 82 insertions(+), 8 deletions(-) -- 1.7.6.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
xhci_hcd fails USB2.0 camera that worked on ehci_hcd
My USB2.0 cameras are enumerated fine on ehci systems. But not on my new Ubuntu 12.10: $uname -a Linux VAIO 3.5.0-18-generic #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux here xhci_hcd is compiled in the kernel, and the device is not enumerated. I tried unbinding xhci using the sysfs and the messages dissapear, but ehci does not take over. Any idea? [12241.536789] usb 3-1: new high-speed USB device number 8 using xhci_hcd [12241.553375] usb 3-1: device descriptor read/8, error -75 [12241.673302] usb 3-1: device descriptor read/8, error -75 [12241.888420] usb 3-1: new high-speed USB device number 9 using xhci_hcd [12241.905029] usb 3-1: device descriptor read/8, error -75 [12242.024764] usb 3-1: device descriptor read/8, error -75 [12242.240032] usb 3-1: new high-speed USB device number 10 using xhci_hcd [12242.256595] usb 3-1: device descriptor read/8, error -75 [12242.376524] usb 3-1: device descriptor read/8, error -75 [12242.591580] usb 3-1: new high-speed USB device number 11 using xhci_hcd [12242.608170] usb 3-1: device descriptor read/8, error -75 [12242.727987] usb 3-1: device descriptor read/8, error -75 [12242.831348] hub 3-0:1.0: unable to enumerate USB device on port 1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: tegra: Using devm API for memory allocation
Using devm_kzalloc for allocating memory needed for PHY pointer and hence removing kfree calls to PHY pointer. Signed-off-by: Venu Byravarasu --- drivers/usb/phy/tegra_usb_phy.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c index 9d13c81..0b99e1f 100644 --- a/drivers/usb/phy/tegra_usb_phy.c +++ b/drivers/usb/phy/tegra_usb_phy.c @@ -704,7 +704,6 @@ static void tegra_usb_phy_close(struct usb_phy *x) utmip_pad_close(phy); clk_disable_unprepare(phy->pll_u); clk_put(phy->pll_u); - kfree(phy); } static int tegra_usb_phy_power_on(struct tegra_usb_phy *phy) @@ -740,7 +739,7 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device *dev, int instance, int i; int err; - phy = kmalloc(sizeof(struct tegra_usb_phy), GFP_KERNEL); + phy = devm_kzalloc(dev, sizeof(struct tegra_usb_phy), GFP_KERNEL); if (!phy) return ERR_PTR(-ENOMEM); @@ -791,7 +790,6 @@ err1: clk_disable_unprepare(phy->pll_u); clk_put(phy->pll_u); err0: - kfree(phy); return ERR_PTR(err); } EXPORT_SYMBOL_GPL(tegra_usb_phy_open); -- 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] usb: host: tegra: make use of PHY pointer of HCD
As pointer to PHY structure can be stored in struct usb_hcd
making use of it, to call PHY APIs.
Call to usb_phy_shutdown() is moved up in tegra_ehci_remove(),
so that to avoid dereferencing of hcd after its freed up.
Signed-off-by: Venu Byravarasu
---
This patch depends on patch
http://marc.info/?l=linux-kernel&m=135581274019690&w=2.
Without above patch applied, phy->notify_connect & phy->notify_disconnect are
set to some unknown values, which need not be NULL.
This creates problem when hcd->phy pointer is initialized hub_port_init() in
hub.c
calls usb_phy_notify_connect().
Stephen,
Can you plz take this patch through tegra tree, so as to take care of the
dependencies?
drivers/usb/host/ehci-tegra.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index aca6606..5b2c48d 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -53,7 +53,7 @@ static void tegra_ehci_power_up(struct usb_hcd *hcd)
clk_prepare_enable(tegra->emc_clk);
clk_prepare_enable(tegra->clk);
- usb_phy_set_suspend(&tegra->phy->u_phy, 0);
+ usb_phy_set_suspend(hcd->phy, 0);
tegra->host_resumed = 1;
}
@@ -62,7 +62,7 @@ static void tegra_ehci_power_down(struct usb_hcd *hcd)
struct tegra_ehci_hcd *tegra = dev_get_drvdata(hcd->self.controller);
tegra->host_resumed = 0;
- usb_phy_set_suspend(&tegra->phy->u_phy, 1);
+ usb_phy_set_suspend(hcd->phy, 1);
clk_disable_unprepare(tegra->clk);
clk_disable_unprepare(tegra->emc_clk);
}
@@ -716,9 +716,14 @@ static int tegra_ehci_probe(struct platform_device *pdev)
goto fail_io;
}
- usb_phy_init(&tegra->phy->u_phy);
+ hcd->phy = &tegra->phy->u_phy;
+ err = usb_phy_init(hcd->phy);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to initialize phy\n");
+ goto fail;
+ }
- err = usb_phy_set_suspend(&tegra->phy->u_phy, 0);
+ err = usb_phy_set_suspend(hcd->phy, 0);
if (err) {
dev_err(&pdev->dev, "Failed to power on the phy\n");
goto fail;
@@ -764,7 +769,7 @@ fail:
if (!IS_ERR_OR_NULL(tegra->transceiver))
otg_set_host(tegra->transceiver->otg, NULL);
#endif
- usb_phy_shutdown(&tegra->phy->u_phy);
+ usb_phy_shutdown(hcd->phy);
fail_io:
clk_disable_unprepare(tegra->emc_clk);
fail_emc_clk:
@@ -787,12 +792,10 @@ static int tegra_ehci_remove(struct platform_device *pdev)
if (!IS_ERR_OR_NULL(tegra->transceiver))
otg_set_host(tegra->transceiver->otg, NULL);
#endif
-
+ usb_phy_shutdown(hcd->phy);
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
- usb_phy_shutdown(&tegra->phy->u_phy);
-
clk_disable_unprepare(tegra->clk);
clk_disable_unprepare(tegra->emc_clk);
--
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
Re: [PATCH 1/1] usb: host: xhci: remove unused trb var in xhci_irq()
On 12/17/2012 11:40 PM, Sarah Sharp wrote: > Hi Javier, > > Thanks for catching this! The patch is going to have to wait until > after the 3.8 merge window closes, since I believe Greg isn't accepting > usb-next pull requests yet. > > Sarah Sharp > > On Sun, Dec 16, 2012 at 04:21:31AM +0100, Javier Martinez Canillas wrote: Hi Sarah, Ok, no worries. Thanks a lot and best regards, Javier -- 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
