Re: [PATCH] USB: plusb: Add support for PL-2501
From: kyak Date: Tue, 24 Jul 2012 09:39:40 +0400 (MSK) > This patch was created against linux-3.5, but it applies perfectly > against net-next tree, i just checked.. > > I'm sorry for not being able to submit the correct patch from the > first attempt (and not even from the third attempt). Could you be more > specific about "doesn't apply cleanly at all"? "git am your_patch" fails. -- 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: plusb: Add support for PL-2501
This patch was created against linux-3.5, but it applies perfectly against net-next tree, i just checked.. I'm sorry for not being able to submit the correct patch from the first attempt (and not even from the third attempt). Could you be more specific about "doesn't apply cleanly at all"? By the way, i'm perfectly fine if you just make this trivial change by yourself and take the credit, because our exchange of e-mails has become 20 times bigger than the patch itself. Probably sending another version of this patch from my side would be just another waste of (your) time. On Mon, 23 Jul 2012, David Miller wrote: From: kyak Date: Mon, 23 Jul 2012 15:44:11 +0400 (MSK) From: Mikhail Peselnik This patch adds support for PL-2501 by adding the appropriate USB ID's. This chip is used in several USB 'Easy Trasfer' Cables. Signed-off-by: Mikhail Peselnik Tested-by: Mikhail Peselnik This does not apply cleanly to my net-next tree at all. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel tracing options with USB subsystem
Hello Greg, On Fri, Jul 20, 2012 at 11:30 PM, Greg KH wrote: > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Fri, Jul 20, 2012 at 10:14:57PM +0530, Balakumar wrote: >> Hi Greg, >> >> When it comes to embedded device cases, I feel that the options are >> just left with debug messages. It becomes really difficult to debug >> some SMP specific issues, thread deadlocks etc. I felt that, using >> trace events, we could effectively log some of those specific data >> without the penalty of compromising latency which happens with >> printks. > > Again, where in the usb core are we using printks for tracing? We don't > do that except for the "usb snoop" mode for usbfs, and that's there > primarily to help reverse engineer other operating systems, and it works > pretty well for that task. I am sorry that I did not make myself clear with the printks. As you have mentioned the core or the gadget framework does not have printk. But, during debugging, to understand the control flow, I would be adding some printk at the desired locations. During a data transfer this printk would get hit a number of timer and floods the dmesg. To quote an example, the request getting queued to the controller, the stats regarding that request (actual length, total length, status) etc. Some gadget drivers try to queue data from both the application and the irq context. (e.g. u_serial.c) In such cases, I felt that an appropriately placed trace event would log on the task which is queuing that request, the CPU id (if applicable) plus the additional parameter we request to log during that time. I feel that such information getting logged into the trace ring buffer would be helpful during a crash/hang case. > >> usbmon is perfect, but USB-centric. The background behind my queries >> was that, is there someway we could trace out whats happening in the >> USB which also contains the kernel information, like the cpu%d it is >> running, the task context etc. >> >> I am fairly new to linux, so please correct me if I got my >> understanding wrong :) > > usbmon is usb-centric, as that is what it was written for. What exactly > are you wanting to see here that could help you out more than what > usbmon provides? > > usbmon is there to monitor the flow of data across the usb wire, not to > do any performance testing or really care about anything outside of the > USB core at all. If you need/want more, we will be glad to work to > provide it, but we need specific use-cases and examples to work off of. > > So, to start with, what specific problems are you having with USB on > your platform that you need better tracing information for to help > resolve the issues? I am working on a basic framework now which would try to log such data using the trace events. I will try to get some trace logs (+ relevant dmesg and usbmon logs) ASAP, so that you can help me. Many Thanks, ~Bala > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: otg: sharing resources between host and gadget
On Mon, Jul 23, 2012 at 5:51 PM, Valentin Sitdikov wrote: > Hello All, > > Could somebody recommend me what is the standard way to share > resources between host and gadget? > > I have seen at least two implementation: > 1. Using suspend/resume: OTG driver resumes or suspends host and > device accordingly to otg state (value ID pin for example) > 2. Device registration/unregistration: OTG driver > registers/unregisters host device accordingly to otg state . > > What is most preferable way to implement? > The second one, the suspend/resume method will give lots of relation between host and gadget. msm and chipidea design is an good example. > How should user-space applications handle possibility of switching > between host and gadget mode (for example libusb if controller is > working as gadget ?) > > Thanks in advance, > Valentin. > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: g_serial and cdc_acm communications
Dipen Patel wrote: > Can anyone help me with this? How my application should detect device > plugout/plugin and SET_CONFIGURATION events? > > Is my current solution of generating input event on SET_CONFIGURATION > call for application to close and reopen device node is Okay? I don't think g_serial should provide an input event.. That doesn't make much sense. Is there no other event delivery mechanism you can use that is already part of the g_serial gadget API? //Peter -- 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: controlling record light on camera
Adam Wozniak wrote:
> so I know this is a "control output" message with "setup" values
> bmRequestType=21, bRequest=01, wValue=0900, wIndex=0700, wLength=0005
> and data of 01,0N,00,00,0a where N=1 for on and N=0 for off
>
> How would I send this same packet from a userspace application?
Install a libusb-1.0 API provider. I suggest libusb-1.0.9 because I
maintain libusb. I think the author of the kernel driver for your
camera works on the libusbx fork of libusb, so he will probably
suggest libusbx-1.0.12.
--8<-- test.c
/* build: gcc $(pkg-config --cflags --libs libusb-1.0) -o test test.c */
/* run:
* ./test 0 # turns light off
* ./test # with non-zero parameter or without parameter turns light on
*/
#include
#include
#include
#define TIMEOUT_MS 1000 /* arbitrarily chosen millisecond timeout */
/* USB Video Class 1.1 documentation:
* http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1_090711.zip
*/
#define UVC_SET_CUR 0x01 /* bRequest per USB Video Class 1.1 Table A-8 */
#define UVC_CS 0x09 /* See about wValue in USB Video Class 1.1 Table 4-4 */
int main(int argc, char *argv[]) {
int ret = 1;
libusb_device_handle *dh;
unsigned char data[] = { 0x01, 0x01, 0x00, 0x00, 0x0a };
if (libusb_init(NULL))
return ret;
dh = libusb_open_device_with_vid_pid(NULL, 0x046d, 0x0825);
if (NULL == dh) {
fprintf(stderr, "open vid:pid 046d:0825 failed\n");
goto done;
}
if (argc > 1)
data[1] = !!atoi(argv[1]);
printf("Turning light %s now...\n", data[1] ? "on" : "off");
fflush(stdout);
ret = libusb_control_transfer(dh,
LIBUSB_REQUEST_TYPE_CLASS | LIBUSB_RECIPIENT_INTERFACE, /* 0x21 */
UVC_SET_CUR, (UVC_CS << 8), 0x0700, data, sizeof(data), TIMEOUT_MS);
if (ret) {
fprintf(stderr, "libusb_control_transfer() returned %d\n", ret);
goto done;
}
ret = 0;
done:
if (dh)
libusb_close(dh);
libusb_exit(NULL);
return ret;
}
-->8--
BUT! Since this is a recipient=interface request it is not
neccessarily true that wIndex=0x0700 is always correct.
wIndex identifies *which* interface in the device that the request is
destined for, and if any other of the many interface altsettings has
been set by the Linux uvc driver then the 0x0700 will not
neccessarily be correct anymore.
AND! Since this is a type=class request with recipient=interface this
code goes behind the back of the kernel driver which is handling the
interface, and that could lead to corrupted internal state in the
kernel, since it is reasonable for a driver to expect that noone else
will go poking at the device!
The above is very portable code because it uses libusb. But since the
particular USB interface is a standard device class it is worth
investigating if the Linux kernel driver for the USB video class
already exposes this LED control operation to userspace in some way.
The kernel has LED infrastructure, so the kernel driver might already
expose your camera LED there. That would be the appropriate and
friendly (to the driver) way to control the LED in Linux. Of course
it does not work on other systems.
//Peter
--
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
[Resend PATCH v2] usb: gadget: s3c-hsotg: fix core reset timeout failure
From: "Du, Changbin"
The timeout values were 1000 and timeout issue occured many times on my
s3c6410 Soc based board (mostly when booting whith USB cable not
connected). This patch increase the values to 1 to guarantee the
success of reset.
Having set timeout to 1, I printed the remained timeout values
which could cause timeout issue before this change (tested several
times).
the first timeout value remained:
timeout = 8079
timeout = 8079
timeout = 8078
timeout = 8081
the second timeout value remained:
timeout = 7940
timeout = 7945
timeout = 7940
timeout = 7938
Seeing from above values, I think the value 1 is big enough.
Signed-off-by: Du, Changbin
---
Changes for v2:
Fixed wrapped line done by my mail client
---
drivers/usb/gadget/s3c-hsotg.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index f4abb0e..f3e2234 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -2215,7 +2215,7 @@ static int s3c_hsotg_corereset(struct s3c_hsotg *hsotg)
/* issue soft reset */
writel(GRSTCTL_CSftRst, hsotg->regs + GRSTCTL);
- timeout = 1000;
+ timeout = 1;
do {
grstctl = readl(hsotg->regs + GRSTCTL);
} while ((grstctl & GRSTCTL_CSftRst) && timeout-- > 0);
@@ -2225,7 +2225,7 @@ static int s3c_hsotg_corereset(struct s3c_hsotg *hsotg)
return -EINVAL;
}
- timeout = 1000;
+ timeout = 1;
while (1) {
u32 grstctl = readl(hsotg->regs + GRSTCTL);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb sound issue ...
On Mon, Jul 23, 2012 at 04:17:54PM -0700, Sarah Sharp wrote: > On Mon, Jul 23, 2012 at 03:22:07PM -0700, Sarah Sharp wrote: > > On Mon, Jul 23, 2012 at 08:31:08PM +0200, Dr. Ing. Dieter Jurzitza wrote: > > > Dear Sarah, > > > dear Andiry, > > > I kindly want to re-rise my question though being quite sure that both of > > > you > > > are busy, not waiting for extra efforts to come along. > > > > > > If you do not find to dig any deepter into this I will keep the solution > > > that > > > had had been provided by Andiry, however, I think it is not more than a > > > plaster. > > > > > > _If_ you find the time to look into, please advise on how to test further. > > > Thank both of you very much for your time, > > > take care > > > > Hi Dr. Jurzitza, > > > > Can you compile a custom kernel with command cancellation support? I > > think that will fix your issue. > > > > You can checkout the code by running: > > > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b > > for-usb-next-set-addr > > > > Please send me dmesg with xHCI debugging turned on, whether it works or > > not. I'd like to confirm that the command cancellation code was the fix > > that helped, or if it's not working, why. > > Actually, relooking over the thread, I need to make an additional patch > on top of the command cancelation patches to extend the work to > configure endpoint commands. So don't test just yet. Gack, I spoke without looking at the patchset. Apparently it does cover configure endpoint commands, so please test it. Sorry for the confusion. 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: usb sound issue ...
On Mon, Jul 23, 2012 at 03:22:07PM -0700, Sarah Sharp wrote: > On Mon, Jul 23, 2012 at 08:31:08PM +0200, Dr. Ing. Dieter Jurzitza wrote: > > Dear Sarah, > > dear Andiry, > > I kindly want to re-rise my question though being quite sure that both of > > you > > are busy, not waiting for extra efforts to come along. > > > > If you do not find to dig any deepter into this I will keep the solution > > that > > had had been provided by Andiry, however, I think it is not more than a > > plaster. > > > > _If_ you find the time to look into, please advise on how to test further. > > Thank both of you very much for your time, > > take care > > Hi Dr. Jurzitza, > > Can you compile a custom kernel with command cancellation support? I > think that will fix your issue. > > You can checkout the code by running: > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b > for-usb-next-set-addr > > Please send me dmesg with xHCI debugging turned on, whether it works or > not. I'd like to confirm that the command cancellation code was the fix > that helped, or if it's not working, why. Actually, relooking over the thread, I need to make an additional patch on top of the command cancelation patches to extend the work to configure endpoint commands. So don't test just yet. 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
[RFT] xhci: Increase reset timeout for renesas 720201 host.
The NEC/Renesas 720201 xHCI host controller does not complete its reset
within 250 milliseconds. Let's increase the timeout to 10 seconds and
use the new debugging in handshake to see how long the host controller
actually needs.
Signed-off-by: Sarah Sharp
Reported-by: e.kleinment...@zonnet.nl
---
drivers/usb/host/xhci.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 7648b2d..4b1bec4 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -61,8 +61,11 @@ static int handshake(struct xhci_hcd *xhci, void __iomem
*ptr,
if (result == ~(u32)0) /* card removed */
return -ENODEV;
result &= mask;
- if (result == done)
+ if (result == done) {
+ xhci_dbg(xhci, "%s done after %u microseconds.\n",
+ __func__, usec);
return 0;
+ }
udelay(1);
usec--;
} while (usec > 0);
@@ -152,7 +155,7 @@ int xhci_reset(struct xhci_hcd *xhci)
{
u32 command;
u32 state;
- int ret, i;
+ int ret, i, usec;
state = xhci_readl(xhci, &xhci->op_regs->status);
if ((state & STS_HALT) == 0) {
@@ -166,7 +169,7 @@ int xhci_reset(struct xhci_hcd *xhci)
xhci_writel(xhci, command, &xhci->op_regs->command);
ret = handshake(xhci, &xhci->op_regs->command,
- CMD_RESET, 0, 250 * 1000);
+ CMD_RESET, 0, 10 * 1000 * 1000);
if (ret)
return ret;
@@ -175,7 +178,13 @@ int xhci_reset(struct xhci_hcd *xhci)
* xHCI cannot write to any doorbells or operational registers other
* than status until the "Controller Not Ready" flag is cleared.
*/
- ret = handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, 250 * 1000);
+ usec = 1000 * 1000;
+ ret = handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, usec);
+ if (ret) {
+ xhci_dbg(xhci, "Host not ready after %u microseconds.\n",
+ usec);
+ return ret;
+ }
for (i = 0; i < 2; ++i) {
xhci->bus_state[i].port_c_suspend = 0;
--
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: usb sound issue ...
On Mon, Jul 23, 2012 at 08:31:08PM +0200, Dr. Ing. Dieter Jurzitza wrote: > Dear Sarah, > dear Andiry, > I kindly want to re-rise my question though being quite sure that both of you > are busy, not waiting for extra efforts to come along. > > If you do not find to dig any deepter into this I will keep the solution that > had had been provided by Andiry, however, I think it is not more than a > plaster. > > _If_ you find the time to look into, please advise on how to test further. > Thank both of you very much for your time, > take care Hi Dr. Jurzitza, Can you compile a custom kernel with command cancellation support? I think that will fix your issue. You can checkout the code by running: git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b for-usb-next-set-addr Please send me dmesg with xHCI debugging turned on, whether it works or not. I'd like to confirm that the command cancellation code was the fix that helped, or if it's not working, why. 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: qmi wwan interface does not work in this version 3.5.rc7.next.20120720
Alan Stern writes: > On Mon, 23 Jul 2012, Bjørn Mork wrote: > >> >>>[ 243.148375] option1 ttyUSB0: GSM modem (1-port) converter now >> >>>disconnected from ttyUSB0 >> >>>[ 243.148471] BUG: unable to handle kernel NULL pointer dereference at >> >>> (null) >> >>>[ 243.148508] IP: [] stop_read_write_urbs+0x37/0x80 >> >>>[usb_wwan] >> >> Yes, this is easily reproducible with any driver based on usb_wwan. >> I've tested both qcserial and option. The immediate cause of this is >> that the &port->dev drvdata is NULL when stop_read_write_urbs is called, >> so that >> >> portdata = usb_get_serial_port_data(port); >> >> ends up being NULL. This problem can also hit in resume I believe. I >> think some of the solution may be moving device_del from disconnect to >> destroy (cut'n paste patch - probably white space damaged): > > No, that's definitely not the way to go. Yes, I suspected that was just papering over part of the problem.. > I suspect that answer is to make usb_wwan_disconnect a .port_remove > callback instead of a .disconnect callback. By the time the disconnect > method runs, the ports have been unregistered and are basically gone. I have a hard time trying to figure out the logic in usb_wwan. There is the usb_wwan_release which is called from destroy_serial, attempting to access and free driver specific serial_port_data. And there is the usb_wwan_disconnect which is called from the USB driver disconnect, and will attempt to kill a number of urbs stored in the serial_port_data. This seems a bit backwards, and AFAICS both of these must expect to be called after the port is gone. Should both be merged and converted to a .port_remove callback? That does seem sanest, given that they operate on port data. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serious problems with empty port power management in linux-next
Alan Stern writes: > On Mon, 23 Jul 2012, Bjørn Mork wrote: > >> Hello, >> >> I have no idea where to start debugging this. But USB hotplug does not >> seem to work at all in linux-next if autosuspend is enabled. >> >> I am running next-20120723 with this: >> >> nemi:/tmp# grep . /sys/bus/usb/devices/usb*/power/control >> /sys/bus/usb/devices/usb1/power/control:auto >> /sys/bus/usb/devices/usb2/power/control:auto >> /sys/bus/usb/devices/usb3/power/control:auto >> /sys/bus/usb/devices/usb4/power/control:auto >> /sys/bus/usb/devices/usb5/power/control:auto >> /sys/bus/usb/devices/usb6/power/control:auto >> /sys/bus/usb/devices/usb7/power/control:auto >> /sys/bus/usb/devices/usb8/power/control:auto >> >> >> Connecting a device to any port, whether it is external or internal >> (using rfkill to "connect") has no effect. Nothing in the log. No >> uevent. >> >> Setting control to "on" on a port will reenable hotplug on that port. >> Any device connected while in "auto" state will suddenly be discovered. > > This sounds like a bug in the host controller driver. What HCDs are > you using? Does the host controller also get suspended? uhci_hcd + ehci_hcd. Really standard intel based laptop from 2008/2009: bjorn@nemi:~$ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) 00:03.0 Communication controller [0780]: Intel Corporation Mobile 4 Series Chipset MEI Controller [8086:2a44] (rev 07) 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) 00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) 00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) 00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03) 00:1f.2 SATA controller [0106]: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] [8086:2929] (rev 03) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03) 03:00.0 Network controller [0280]: Intel Corporation Ultimate N WiFi Link 5300 [8086:4236] Is this indicating host controller suspend? If so, then yes: Jul 23 23:27:39 nemi kernel: [ 1334.680513] uhci_hcd :00:1a.2: power state changed by ACPI to D3 Jul 23 23:27:39 nemi kernel: [ 1334.695357] uhci_hcd :00:1d.0: power state changed by ACPI to D3 Jul 23 23:27:41 nemi kernel: [ 1336.824658] uhci_hcd :00:1a.0: power state changed by ACPI to D3 Jul 23 23:27:42 nemi kernel: [ 1336.856298] ehci_hcd :00:1d.7: power state changed by ACPI to D3 Jul 23 23:27:42 nemi kernel: [ 1336.856350] ehci_hcd :00:1a.7: power state changed by ACPI to D3 Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Monday 23 July 2012 15:55:51 Alan Stern wrote: > The runtime PM framework already provides such an API, although the USB > layer doesn't have a wrapper for it. That should be rectified. > I suggest that rather than have usb-storage mess around with details > like no medium or offline, the SCSI layer should handle such things. > Lin Ming's patches (not yet accepted) allow SCSI disks to autosuspend > at appropriate times. When this happens, usb-storage might as well > autosuspend almost immediately. I agree. It is better to do this at the SCSI level. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Help with EHCI Missing Bulk In Callbacks
Hello, Unfortunately this is a very hard problem to recreate and I've had to give this one a lower priority. However, I did add the code change you mentioned as I'm waiting for it to happen again. Below are the values of the status and command registers during normal operation when the issue has not occurred. I'll send a response when it does happen with the register values. Also, moving to a new kernel won't be possible due to restrictions from other SW items on the system I'm working on. Thank you for the response. Daniel P Graves Status Register --- Swaps between the following two values: 1100 1001 (Asynchronous Schedule Status,Periodic Schedule Status,Frame List Rollover,USB Interrupt) A 009 1100 0010 1000 (Asynchronous Schedule Status,Periodic Schedule Status,Interrupt on Async Advance,Frame List Rollover) A028 Cmd Register Always the following value: 0001 0010 0001 (Interrupt Threshold Control,Asynchronous Schedule Enable,Run/Stop) 10021 -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Monday, July 23, 2012 1:50 PM To: Graves, Daniel (GE Healthcare) Cc: linux-usb@vger.kernel.org Subject: RE: Help with EHCI Missing Bulk In Callbacks On Sat, 16 Jun 2012, Graves, Daniel (GE Healthcare) wrote: > Hello, > > wMaxPacketSize if 512. The transfer_buffer_length the problematic > message is 8. And yes I meant scan_async doesn't run until 4 seconds > later. > > Yes the debug messages I gave were just to show the time discrepancy > between each message. The first line of each time interval is > printed inside of scan_async to prove that scan_async is delayed by 4 > seconds. > > Thanks for mentioning the patch. I will look into it. Was this ever resolved? It may be that your problem was fixed by a change to ehci-hcd made about a year ago. Have you tried using a more recent kernel (3.1 or later)? 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] qcserial: fix port handling on Gobi 1K and 2K+
On Mon, 2012-07-23 at 22:23 +0200, Bjørn Mork wrote: > Dan Williams writes: > > > Bjorn's latest patchset does break Gobi 1K and 2K because on both > > devices as it claims usb interface 0. That's because usbif 0 is not > > handled in the switch statement, and thus the if0 gets claimed when it > > should not. So let's just make things even simpler yet, and handle both > > the 1K and 2K+ cases separately. > > Ouch. Yes, I feared I would do something like that. Thanks for testing > and fixing. Sorry it took so long to get around to it :( Dan > > This patch should not affect the new > > Sierra device support, because those devices are matched via > > interface-specific matching and thus should never hit the composite > > code. > > FWIW, I've tested and verified that it still works with the Sierra > MC7710. > > > Bjørn > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] qcserial: fix port handling on Gobi 1K and 2K+
Dan Williams writes: > Bjorn's latest patchset does break Gobi 1K and 2K because on both > devices as it claims usb interface 0. That's because usbif 0 is not > handled in the switch statement, and thus the if0 gets claimed when it > should not. So let's just make things even simpler yet, and handle both > the 1K and 2K+ cases separately. Ouch. Yes, I feared I would do something like that. Thanks for testing and fixing. > This patch should not affect the new > Sierra device support, because those devices are matched via > interface-specific matching and thus should never hit the composite > code. FWIW, I've tested and verified that it still works with the Sierra MC7710. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serious problems with empty port power management in linux-next
On Mon, 23 Jul 2012, Bjørn Mork wrote: > Hello, > > I have no idea where to start debugging this. But USB hotplug does not > seem to work at all in linux-next if autosuspend is enabled. > > I am running next-20120723 with this: > > nemi:/tmp# grep . /sys/bus/usb/devices/usb*/power/control > /sys/bus/usb/devices/usb1/power/control:auto > /sys/bus/usb/devices/usb2/power/control:auto > /sys/bus/usb/devices/usb3/power/control:auto > /sys/bus/usb/devices/usb4/power/control:auto > /sys/bus/usb/devices/usb5/power/control:auto > /sys/bus/usb/devices/usb6/power/control:auto > /sys/bus/usb/devices/usb7/power/control:auto > /sys/bus/usb/devices/usb8/power/control:auto > > > Connecting a device to any port, whether it is external or internal > (using rfkill to "connect") has no effect. Nothing in the log. No > uevent. > > Setting control to "on" on a port will reenable hotplug on that port. > Any device connected while in "auto" state will suddenly be discovered. This sounds like a bug in the host controller driver. What HCDs are you using? Does the host controller also get suspended? 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: mount stuck, khubd blocked
Alan Stern writes: > On Mon, 23 Jul 2012, Jeff Moyer wrote: > >> > Jeff, does this also fix Bugzilla #43269? >> >> First, this patch is wrong. I posted another version later on that got >> merged for 3.5. >> >> As for bug 43269, it does not look like the same symptoms, so I would >> not expect the patches I posted to resolve that issue. Sorry. > > Can you suggest someone who might be able to help with #43269? It has > been languishing since May. Well, either Jens or James may be able to make more progress faster than I could. I'm a little concerned that the reporter has unreasonable expectations for his use of library calls, but I suppose that's a separate issue. James, Jens: https://bugzilla.kernel.org/show_bug.cgi?id=43269 Cheers, Jeff -- 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: qmi wwan interface does not work in this version 3.5.rc7.next.20120720
On Mon, 23 Jul 2012, Bjørn Mork wrote: > >>>[ 243.148375] option1 ttyUSB0: GSM modem (1-port) converter now > >>>disconnected from ttyUSB0 > >>>[ 243.148471] BUG: unable to handle kernel NULL pointer dereference at > >>> (null) > >>>[ 243.148508] IP: [] stop_read_write_urbs+0x37/0x80 > >>>[usb_wwan] > > Yes, this is easily reproducible with any driver based on usb_wwan. > I've tested both qcserial and option. The immediate cause of this is > that the &port->dev drvdata is NULL when stop_read_write_urbs is called, > so that > > portdata = usb_get_serial_port_data(port); > > ends up being NULL. This problem can also hit in resume I believe. I > think some of the solution may be moving device_del from disconnect to > destroy (cut'n paste patch - probably white space damaged): No, that's definitely not the way to go. I suspect that answer is to make usb_wwan_disconnect a .port_remove callback instead of a .disconnect callback. By the time the disconnect method runs, the ports have been unregistered and are basically gone. 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: plusb: Add support for PL-2501
From: kyak Date: Mon, 23 Jul 2012 15:44:11 +0400 (MSK) > From: Mikhail Peselnik > > This patch adds support for PL-2501 by adding the appropriate USB > ID's. This chip is used in several USB 'Easy Trasfer' Cables. > > Signed-off-by: Mikhail Peselnik > Tested-by: Mikhail Peselnik This does not apply cleanly to my net-next tree at all. -- 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
Serious problems with empty port power management in linux-next
Hello, I have no idea where to start debugging this. But USB hotplug does not seem to work at all in linux-next if autosuspend is enabled. I am running next-20120723 with this: nemi:/tmp# grep . /sys/bus/usb/devices/usb*/power/control /sys/bus/usb/devices/usb1/power/control:auto /sys/bus/usb/devices/usb2/power/control:auto /sys/bus/usb/devices/usb3/power/control:auto /sys/bus/usb/devices/usb4/power/control:auto /sys/bus/usb/devices/usb5/power/control:auto /sys/bus/usb/devices/usb6/power/control:auto /sys/bus/usb/devices/usb7/power/control:auto /sys/bus/usb/devices/usb8/power/control:auto Connecting a device to any port, whether it is external or internal (using rfkill to "connect") has no effect. Nothing in the log. No uevent. Setting control to "on" on a port will reenable hotplug on that port. Any device connected while in "auto" state will suddenly be discovered. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mount stuck, khubd blocked
On Mon, 23 Jul 2012, Jeff Moyer wrote: > > Jeff, does this also fix Bugzilla #43269? > > First, this patch is wrong. I posted another version later on that got > merged for 3.5. > > As for bug 43269, it does not look like the same symptoms, so I would > not expect the patches I posted to resolve that issue. Sorry. Can you suggest someone who might be able to help with #43269? It has been languishing since May. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Mon, 23 Jul 2012, Oliver Neukum wrote: > On Monday 23 July 2012 11:08:47 Sarah Sharp wrote: > > > By disabling this, you are not creating a real-world situation. Those > > > disks need to be polled for a reason, right? > > > > Tianyu is trying to test the port power off mechanism with USB 3.0 > > devices, to make sure the patches work on USB 3.0. Since the majority > > of USB 3.0 devices are storage, he needs to disable the polling to run > > tests. > > > > Yes, killing udev is an extreme measure, and using Alan's suggestion to > > stop the block device polling file is better. Yes, this is just a test > > and not something we can do in a real Linux distro. > > This would be an ideal time to extend the API to allow a driver to set > the timeout for autosuspend to zero. The storage driver should use > this if all its children have reported -ENOMEDIUM or are offlined. The runtime PM framework already provides such an API, although the USB layer doesn't have a wrapper for it. I suggest that rather than have usb-storage mess around with details like no medium or offline, the SCSI layer should handle such things. Lin Ming's patches (not yet accepted) allow SCSI disks to autosuspend at appropriate times. When this happens, usb-storage might as well autosuspend almost immediately. In other words, userspace could be encouraged to set the autosuspend delay for USB mass-storage devices to something a lot smaller than 2 seconds. I'm not so sure it's a good idea for usb-storage to do this, because it might end up overwriting a setting given by the user. Also, it's probably not a good idea for composite devices. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Monday 23 July 2012 11:08:47 Sarah Sharp wrote: > > By disabling this, you are not creating a real-world situation. Those > > disks need to be polled for a reason, right? > > Tianyu is trying to test the port power off mechanism with USB 3.0 > devices, to make sure the patches work on USB 3.0. Since the majority > of USB 3.0 devices are storage, he needs to disable the polling to run > tests. > > Yes, killing udev is an extreme measure, and using Alan's suggestion to > stop the block device polling file is better. Yes, this is just a test > and not something we can do in a real Linux distro. This would be an ideal time to extend the API to allow a driver to set the timeout for autosuspend to zero. The storage driver should use this if all its children have reported -ENOMEDIUM or are offlined. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] qcserial: fix port handling on Gobi 1K and 2K+
Bjorn's latest patchset does break Gobi 1K and 2K because on both
devices as it claims usb interface 0. That's because usbif 0 is not
handled in the switch statement, and thus the if0 gets claimed when it
should not. So let's just make things even simpler yet, and handle both
the 1K and 2K+ cases separately. This patch should not affect the new
Sierra device support, because those devices are matched via
interface-specific matching and thus should never hit the composite
code.
Signed-off-by: Dan Williams
---
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ca2c3ad..8514d86 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -202,43 +202,49 @@ static int qcprobe(struct usb_serial *serial, const
struct usb_device_id *id)
/* default to enabling interface */
altsetting = 0;
- switch (ifnum) {
- /* Composite mode; don't bind to the QMI/net interface as that
-* gets handled by other drivers.
-*/
+ /* Composite mode; don't bind to the QMI/net interface as that
+* gets handled by other drivers.
+*/
+
+ if (is_gobi1k) {
/* Gobi 1K USB layout:
* 0: serial port (doesn't respond)
* 1: serial port (doesn't respond)
* 2: AT-capable modem port
* 3: QMI/net
-*
-* Gobi 2K+ USB layout:
+*/
+ if (ifnum == 2)
+ dev_dbg(dev, "Modem port found\n");
+ else
+ altsetting = -1;
+ } else {
+ /* Gobi 2K+ USB layout:
* 0: QMI/net
* 1: DM/DIAG (use libqcdm from ModemManager for communication)
* 2: AT-capable modem port
* 3: NMEA
*/
-
- case 1:
- if (is_gobi1k)
+ switch (ifnum) {
+ case 0:
+ /* Don't claim the QMI/net interface */
altsetting = -1;
- else
+ break;
+ case 1:
dev_dbg(dev, "Gobi 2K+ DM/DIAG interface found\n");
- break;
- case 2:
- dev_dbg(dev, "Modem port found\n");
- break;
- case 3:
- if (is_gobi1k)
- altsetting = -1;
- else
+ break;
+ case 2:
+ dev_dbg(dev, "Modem port found\n");
+ break;
+ case 3:
/*
* NMEA (serial line 9600 8N1)
* # echo "\$GPS_START" > /dev/ttyUSBx
* # echo "\$GPS_STOP" > /dev/ttyUSBx
*/
dev_dbg(dev, "Gobi 2K+ NMEA GPS interface found\n");
+ break;
+ }
}
done:
--
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: mount stuck, khubd blocked
Alan Stern writes: > On Wed, 20 Jun 2012, Jeff Moyer wrote: > >> Alan Stern writes: >> >> > On Tue, 19 Jun 2012, Dima Tisnek wrote: >> > >> >> I made a microsd flash with 2 partitions, sdb1 is data partition, and >> >> sdb2 is a sentinel partition, 1 block in size. >> >> >> >> I attached the usb-microsd reader with that card in it and by mistake >> >> tried to mount the sentinel partition, I ran: >> >> mount /dev/sdb2 /mnt/flash/ >> >> >> >> mount got stuck, I was not able to kill or strace it, I pulled the usb >> >> reader from the port, mount was still stuck, here's the dmesg log: >> >> Hi, Dima, >> >> Could you try the following patch? >> >> Thanks, >> Jeff >> >> diff --git a/fs/buffer.c b/fs/buffer.c >> index 838a9cf..769b30b 100644 >> --- a/fs/buffer.c >> +++ b/fs/buffer.c >> @@ -930,7 +930,7 @@ init_page_buffers(struct page *page, struct block_device >> *bdev, >> bh->b_blocknr = block; >> if (uptodate) >> set_buffer_uptodate(bh); >> -if (block < end_block) >> +if (block <= end_block) >> set_buffer_mapped(bh); >> } >> block++; > > Jeff, does this also fix Bugzilla #43269? First, this patch is wrong. I posted another version later on that got merged for 3.5. As for bug 43269, it does not look like the same symptoms, so I would not expect the patches I posted to resolve that issue. Sorry. Cheers, Jeff -- 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: mount stuck, khubd blocked
On Wed, 20 Jun 2012, Jeff Moyer wrote: > Alan Stern writes: > > > On Tue, 19 Jun 2012, Dima Tisnek wrote: > > > >> I made a microsd flash with 2 partitions, sdb1 is data partition, and > >> sdb2 is a sentinel partition, 1 block in size. > >> > >> I attached the usb-microsd reader with that card in it and by mistake > >> tried to mount the sentinel partition, I ran: > >> mount /dev/sdb2 /mnt/flash/ > >> > >> mount got stuck, I was not able to kill or strace it, I pulled the usb > >> reader from the port, mount was still stuck, here's the dmesg log: > > Hi, Dima, > > Could you try the following patch? > > Thanks, > Jeff > > diff --git a/fs/buffer.c b/fs/buffer.c > index 838a9cf..769b30b 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -930,7 +930,7 @@ init_page_buffers(struct page *page, struct block_device > *bdev, > bh->b_blocknr = block; > if (uptodate) > set_buffer_uptodate(bh); > - if (block < end_block) > + if (block <= end_block) > set_buffer_mapped(bh); > } > block++; Jeff, does this also fix Bugzilla #43269? 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: qmi wwan interface does not work in this version 3.5.rc7.next.20120720
>>>[ 243.148375] option1 ttyUSB0: GSM modem (1-port) converter now
>>>disconnected from ttyUSB0
>>>[ 243.148471] BUG: unable to handle kernel NULL pointer dereference at
>>>(null)
>>>[ 243.148508] IP: [] stop_read_write_urbs+0x37/0x80
>>>[usb_wwan]
Yes, this is easily reproducible with any driver based on usb_wwan.
I've tested both qcserial and option. The immediate cause of this is
that the &port->dev drvdata is NULL when stop_read_write_urbs is called,
so that
portdata = usb_get_serial_port_data(port);
ends up being NULL. This problem can also hit in resume I believe. I
think some of the solution may be moving device_del from disconnect to
destroy (cut'n paste patch - probably white space damaged):
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index aa4b0d7..0a57500 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -152,6 +152,8 @@ static void destroy_serial(struct kref *kref)
for (i = 0; i < serial->num_port_pointers; ++i) {
port = serial->port[i];
if (port) {
+ if (device_is_registered(&port->dev))
+ device_del(&port->dev);
port->serial = NULL;
put_device(&port->dev);
}
@@ -1116,8 +1118,6 @@ static void usb_serial_disconnect(struct usb_interface
*interface)
}
kill_traffic(port);
cancel_work_sync(&port->work);
- if (device_is_registered(&port->dev))
- device_del(&port->dev);
}
}
serial->type->disconnect(serial);
But there are so many skeletons in the current usb-next code that I have
a really hard time debugging this. One example: using rfkill
block/unblock to temporarily disconnect the internal modem only works
when connected to AC. If on battery, then nothing happens on reconnect
(no USB device detected). The same happens for Bluetooth as well, so
it's not a serial thingy.
Connecting AC power (this will trigger an autosuspend policy change on
my laptop, and I suspect that is the real differenc) will suddenly make
the devices appear again. Quite a suprise.
I suspect the weird cut-power patches accounts for this, and will send
another mail to flag the problem.
But the end result is that I spent too much of the debugging time I had
today chasing unrelated problems.
BTW, Thomas, I am unable to reproduce your qmi_wwan problems. So I'd
like more details about those. But given the problems I've had today, I
expect you are facing some unrelated problem with the USB core. It is
really unfit for release in usb-next. I'd recommend you run 3.5 on any
production system for now, possibly with a number of cherry-picked
patches if you need some newer feature.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Help with EHCI Missing Bulk In Callbacks
On Sat, 16 Jun 2012, Graves, Daniel (GE Healthcare) wrote: > Hello, > > wMaxPacketSize if 512. The transfer_buffer_length the problematic > message is 8. And yes I meant scan_async doesn't run until 4 seconds > later. > > Yes the debug messages I gave were just to show the time discrepancy > between each message. The first line of each time interval is printed > inside of > scan_async to prove that scan_async is delayed by 4 seconds. > > Thanks for mentioning the patch. I will look into it. Was this ever resolved? It may be that your problem was fixed by a change to ehci-hcd made about a year ago. Have you tried using a more recent kernel (3.1 or later)? 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: usb sound issue ...
Dear Sarah, dear Andiry, I kindly want to re-rise my question though being quite sure that both of you are busy, not waiting for extra efforts to come along. If you do not find to dig any deepter into this I will keep the solution that had had been provided by Andiry, however, I think it is not more than a plaster. _If_ you find the time to look into, please advise on how to test further. Thank both of you very much for your time, take care Dieter Jurzitza On Samstag, 14. Juli 2012 00:58:56 Sarah Sharp wrote: > On Fri, Jul 13, 2012 at 03:19:58PM +0800, Andiry Xu wrote: > > On 07/13/2012 03:19 AM, Dr. Ing. Dieter Jurzitza wrote: -- --- | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / <°°__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) --- -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Mon, Jul 23, 2012 at 08:06:22AM -0700, Greg KH wrote: > On Mon, Jul 23, 2012 at 09:23:53AM +0800, Lan Tianyu wrote: > > On 2012年07月21日 01:08, Sarah Sharp wrote: > > >On Thu, Jul 19, 2012 at 11:42:57AM +0200, Oliver Neukum wrote: > > >>On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote: > > >>>On 2012年07月19日 14:37, Oliver Neukum wrote: > > Moreover, the block layer also will check the disk status periodically. > > AS alan pointed, echo 0 >/sys/block/sdX/events_poll_msec to stop check > > event. So before I tested, I kill udev and disable the block layer check > > event. Finally, I got stable power consumption. I will also test other > > usb3.0 devices. > > By disabling this, you are not creating a real-world situation. Those > disks need to be polled for a reason, right? Tianyu is trying to test the port power off mechanism with USB 3.0 devices, to make sure the patches work on USB 3.0. Since the majority of USB 3.0 devices are storage, he needs to disable the polling to run tests. Yes, killing udev is an extreme measure, and using Alan's suggestion to stop the block device polling file is better. Yes, this is just a test and not something we can do in a real Linux distro. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] xhci: EHCI/XHCI ports switching on Intense-PC.
Did you try disabling the wake on bits in the port status registers? I
would prefer that solution if it works.
Otherwise this patchset looks fine. I'll work with the hardware folks
and see if this is exposed on other boards. Also, this is not a BIOS
bug, but a hardware issue that can be worked around in BIOS. So I might
edit your description on the first patch a bit when I submit it to Greg.
Sarah Sharp
On Mon, Jul 23, 2012 at 02:46:32PM +0300, Denis Turischev wrote:
> Intense-PC is Compulab's mini-desktop with Intel Panther Point
> chipset.
>
> Unconditional switchover to xHCI provided by function
> usb_enable_xhci_ports() leads to surprising results, after shutdown
> system powered-on again after a few seconds. On Windows power
> related problems were not observed. Switching back to EHCI solves
> the problem.
>
> The patch switches usb ports back to EHCI during xhci shutdown
> for Intense-PC.
>
> Signed-off-by: Denis Turischev
> ---
> drivers/usb/host/xhci.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index a979cd0..541efaa 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -26,6 +26,8 @@
> #include
> #include
> #include
> +#include
> +#include "pci-quirks.h"
>
> #include "xhci.h"
>
> @@ -656,8 +658,20 @@ void xhci_stop(struct usb_hcd *hcd)
> */
> void xhci_shutdown(struct usb_hcd *hcd)
> {
> + struct pci_dev *pdev;
> + const char *brd_name;
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>
> + pdev = to_pci_dev(hcd->self.controller);
> +
> + if (usb_is_intel_switchable_xhci(pdev)) {
> + brd_name = dmi_get_system_info(DMI_BOARD_NAME);
> +
> + /* quirk for Compulab's Intense-PC board */
> + if (brd_name && strstr(brd_name, "Intense-PC"))
> + usb_disable_xhci_ports(pdev);
> + }
> +
> spin_lock_irq(&xhci->lock);
> xhci_halt(xhci);
> spin_unlock_irq(&xhci->lock);
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] xhci: provide usb_disable_xhci_ports function for Intel chipsets.
Some devices with Intel Panther Point chipset may require switchover
usb ports from XHCI back to EHCI controller before shutdown.
Otherwise various BIOS bugs related to power management may be
triggered.
v2: deleted unnecessary variables.
Signed-off-by: Denis Turischev
---
drivers/usb/host/pci-quirks.c |7 +++
drivers/usb/host/pci-quirks.h |1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index df0828c..c5e9e4a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -800,6 +800,13 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
}
EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
+{
+ pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
+ pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
+}
+EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+
/**
* PCI Quirks for xHCI.
*
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index b1002a8..ef004a5 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev);
void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
#else
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: otg: sharing resources between host and gadget
On Mon, 23 Jul 2012, Valentin Sitdikov wrote: > Hello All, > > Could somebody recommend me what is the standard way to share > resources between host and gadget? There isn't really any standard way. > I have seen at least two implementation: > 1. Using suspend/resume: OTG driver resumes or suspends host and > device accordingly to otg state (value ID pin for example) > 2. Device registration/unregistration: OTG driver > registers/unregisters host device accordingly to otg state . > > What is most preferable way to implement? In my opinion the second way is better. If all you do is suspend the host, someone might try to resume it at the wrong time. > How should user-space applications handle possibility of switching > between host and gadget mode (for example libusb if controller is > working as gadget ?) The same way they handle detection and removal of the host controller or the device controller. 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: Discussion about implementation of usb port power off mechanism for port with device
On Mon, 23 Jul 2012, Lan Tianyu wrote:
> hi alan:
> I accord to your advice to implement usb port power off mechanism
> for port with device (add "auto" option for portX/control to allow port
> to be power off during device being suspended and power on when resuming).
>
> http://marc.info/?l=linux-usb&m=133675841421390&w=2
> > I still don't see what the problem is. They don't have to be
> > synchronized; all you need to do is make sure that the port's state
> > remains set to "off" until the debouncing is finished and you have
> > turned off the connect-change and enable-change features.
>
> But the device is still disconnected after powering on the port during
> resuming. Caused by that port_power had been set to "on" when connect-change
> event was processed. My patch is at the bottom of the mail. If something
> wrong, please help me to correct. Thanks.
> @@ -3027,6 +3070,24 @@ int usb_port_resume(struct usb_device *u
> int status;
> u16 portchange, portstatus;
>
> + if (hub->ports[port1 - 1]->port_power_policy == USB_PORT_POWER_AUTO
> + && hub->ports[port1 - 1]->power_state ==
> USB_PORT_POWER_STATE_OFF) {
> + set_port_feature(udev->parent, port1, USB_PORT_FEAT_POWER);
> +
> + /*
> + * Wait for usb hub port to be reconnected in order to make
> + * the resume procedure successful.
> + */
> + status = usb_port_wait_for_connected(hub, port1);
> + if (status < 0) {
> + dev_dbg(&udev->dev, "can't get reconnection after
> setting port " \
> + "power on, status %d\n", status);
> + return status;
> + }
> + hub->ports[port1 - 1]->power_state = USB_PORT_POWER_STATE_ON;
> + pr_info("%s: port%d connect state on %ld\n", __func__, port1,
> jiffies);
> + }
> +
> /* Skip the initial Clear-Suspend step for a remote wakeup */
> status = hub_port_status(hub, port1, &portstatus, &portchange);
> if (status == 0 && !port_is_suspended(hub, portstatus))
A few lines later the driver does:
set_bit(port1, hub->busy_bits);
You merely need to move this line up before the point where you turn
port power back on. Make it the first executable line of the function.
> @@ -3058,7 +3119,6 @@ int usb_port_resume(struct usb_device *u
>* sequence.
>*/
> status = hub_port_status(hub, port1, &portstatus, &portchange);
> -
You don't need to remove this blank line.
> /* TRSMRCY = 10 msec */
> msleep(10);
> }
> @@ -4177,6 +4237,13 @@ static void hub_port_connect_change(stru
> }
> }
>
> + if (hub->ports[port1 - 1]->port_power_policy == USB_PORT_POWER_AUTO
> + && hub->ports[port1 - 1]->power_state ==
> USB_PORT_POWER_STATE_OFF) {
Does the policy matter here? I suspect only the power_state is important.
> + clear_bit(port1, hub->change_bits);
> + return;
> + }
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 v3] USB: dwc3-exynos: Add vbus setup function to the exynos dwc3 glue layer
Hi, On Tue, Jul 24, 2012 at 12:09:47AM +0900, Vivek Gautam wrote: > > > @@ -58,6 +81,8 @@ static int __devinit dwc3_exynos_probe(struct > > platform_device *pdev) > > > if (!pdev->dev.coherent_dma_mask) > > > pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); > > > > > > + dwc3_setup_vbus_gpio(pdev); > > > > I think this should be handled by the gpio-vbus transceiver. No ? > > > > I can understand that we can use gpio-vbus transceiver. But i have one > confusion here. > We have ehci as well as this dwc3 which need gpio to be setup to > control vbus. So do we have two instances of this gpio-vbus driver to > facilitate both ehci and dwc3, because both may be on different gpio > lines. Sure... one for dwc3 and one for ehci. > Moreover, the gpio line right now is parsed from the DT node of the > device, so while assigning the 'gpio_vbus' field in > 'gpio_vbus_mach_info', how do we provide that. Please suggest. gpio-vbus doesn't have support for DT today, just add it ;-) > One more suggestion please. Now that we are moving to DT we should be > making changes for gpio-vbus transceiver also for device tree support. yes, it needs support for DT before you can use it then. cheers -- balbi signature.asc Description: Digital signature
Re: Kernel Oops while disconnecting USB peripheral (always)
On 23.07.2012 17:04, Sarbojit Ganguly wrote: > On 23 July 2012 20:17, Alan Stern wrote: > Yes the issue is in evict() api which gets called when USB disconnect > is triggered. >> >> Alan Stern >> > > Even I was confused in the beginning but after thorough check I > confirmed its presence. I reverted back to my distro's stock kernel > (3.2.0-26-generic) where the issue does not recur. > > I could not analysed further (due to my limited knowledge of USB). If you could bisect the problem, that would help a lot. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable "power/wakeup" to control remote wakeup in the runtime suspend
On Mon, Jul 23, 2012 at 09:23:53AM +0800, Lan Tianyu wrote: > Sorry for later reply. :) > > On 2012年07月21日 01:08, Sarah Sharp wrote: > >On Thu, Jul 19, 2012 at 11:42:57AM +0200, Oliver Neukum wrote: > >>On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote: > >>>On 2012年07月19日 14:37, Oliver Neukum wrote: > >> > But this leaves me with a question. Has anybody ever measured the > additional > power savings compared to a suspended state for devices? Or are you doing > this only as a prelude to become able to send host controllers to D3cold? > >>>hi Oliver: > >>> I have done a test on a usb3.0 ORICO SSD which may cost 3w normally. > >>>Traditional suspend can save 1w. Power off can save additional 2w. I also > >>>test > >> > >>Well, then the device violates the standard for power consumption. > > > >Not necessarily. > > > >Tianyu, are you measuring the whole system power consumption or just the > >power drawn by the device? How are you measuring power consumption? > I measure the whole system power consumption. First, boot system and wait > for the power consumption stable. Second, kill udev and disable block layer > check event. Why kill udev? It's not doing anything on its own. > Third, enable the device runtime pm. Observe the power consumption > change. Get result. > > > > >Also, are you sure the mass storage device was actually suspended? > I am sure the device was suspended via power/runtime_status. > > >Unfortunately, userspace polls unmounted drives every two seconds or so > >to see if there's a medium change. So even though you may have enabled > >auto-suspend, userspace will still be waking the device out of suspend > >every two seconds. That might explain your high suspend power > >consumption. > Just like you said, udev may poll usb device drives every two seconds. udev does this? Really? Where does that happen in the udev code? I though that was some cdrom probing stuff from gnome daemons or somewhere else, but not in udev itself. > Moreover, the block layer also will check the disk status periodically. > AS alan pointed, echo 0 >/sys/block/sdX/events_poll_msec to stop check > event. So before I tested, I kill udev and disable the block layer check > event. Finally, I got stable power consumption. I will also test other > usb3.0 devices. By disabling this, you are not creating a real-world situation. Those disks need to be polled for a reason, right? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Oops while disconnecting USB peripheral (always)
On 23 July 2012 20:24, Daniel Mack wrote: > On 23.07.2012 16:47, Alan Stern wrote: >> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: >>> That is why I provided two stacks, >>> >>> 1st one is when I tried to remove the USB hub (which connects a webcam >>> + microphone) >>> 2nd one is when I tried to remove an USB powered external HDD. >>> >>> Just to make sure whether the problem is with USB sound or the USB >>> subsystem. >> >> Do you stop all the programs that are using the USB devices before >> unplugging the hub? Do you unmount the USB HDD first? >> >> The first crash shows a problem in the snd-usb-audio driver. >> >> The second crash shows a problem in the VFS layer or in ext3, not in >> the USB stack. > > I dare to doubt there are two severe bugs of that kind that are 100% > reproducible. I haven't had a hotplug crash in any of the two drivers > for a long time, and I use both of them extensively. > > I rather assume there's something else failing, probably some host > controller issue that corrupts mempory? Can anyone else reproduce this > maybe? > > > > Daniel > I will be happy to provide my .config if that is required. I think that might help in narrowing down the bug -- Regards, Sarbojit -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Oops while disconnecting USB peripheral (always)
On 23 July 2012 20:17, Alan Stern wrote: > On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: > >> Hello Daniel, >> >> That is why I provided two stacks, >> >> 1st one is when I tried to remove the USB hub (which connects a webcam >> + microphone) >> 2nd one is when I tried to remove an USB powered external HDD. >> >> Just to make sure whether the problem is with USB sound or the USB subsystem. > > Do you stop all the programs that are using the USB devices before > unplugging the hub? Do you unmount the USB HDD first? Yes Alan, I did unmount the HDD > > The first crash shows a problem in the snd-usb-audio driver. > > The second crash shows a problem in the VFS layer or in ext3, not in > the USB stack. Yes the issue is in evict() api which gets called when USB disconnect is triggered. > > Alan Stern > Even I was confused in the beginning but after thorough check I confirmed its presence. I reverted back to my distro's stock kernel (3.2.0-26-generic) where the issue does not recur. I could not analysed further (due to my limited knowledge of USB). -- Regards, Sarbojit -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Oops while disconnecting USB peripheral (always)
On 23.07.2012 16:47, Alan Stern wrote: > On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: >> That is why I provided two stacks, >> >> 1st one is when I tried to remove the USB hub (which connects a webcam >> + microphone) >> 2nd one is when I tried to remove an USB powered external HDD. >> >> Just to make sure whether the problem is with USB sound or the USB subsystem. > > Do you stop all the programs that are using the USB devices before > unplugging the hub? Do you unmount the USB HDD first? > > The first crash shows a problem in the snd-usb-audio driver. > > The second crash shows a problem in the VFS layer or in ext3, not in > the USB stack. I dare to doubt there are two severe bugs of that kind that are 100% reproducible. I haven't had a hotplug crash in any of the two drivers for a long time, and I use both of them extensively. I rather assume there's something else failing, probably some host controller issue that corrupts mempory? Can anyone else reproduce this maybe? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Oops while disconnecting USB peripheral (always)
On Mon, 23 Jul 2012, Sarbojit Ganguly wrote: > Hello Daniel, > > That is why I provided two stacks, > > 1st one is when I tried to remove the USB hub (which connects a webcam > + microphone) > 2nd one is when I tried to remove an USB powered external HDD. > > Just to make sure whether the problem is with USB sound or the USB subsystem. Do you stop all the programs that are using the USB devices before unplugging the hub? Do you unmount the USB HDD first? The first crash shows a problem in the snd-usb-audio driver. The second crash shows a problem in the VFS layer or in ext3, not in the USB stack. 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] xhci: provide usb_disable_xhci_ports function for Intel chipsets.
Hello.
On 07/23/2012 03:46 PM, Denis Turischev wrote:
> Some devices with Intel Panther Point chipset may require switchover
> usb ports from XHCI back to EHCI controller before shutdown.
> Overwise various BIOS bugs related to power management may be
> triggered.
> Signed-off-by: Denis Turischev
> ---
> drivers/usb/host/pci-quirks.c | 14 ++
> drivers/usb/host/pci-quirks.h |1 +
> 2 files changed, 15 insertions(+)
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index df0828c..b19a84a 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -800,6 +800,20 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
> }
> EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
>
> +void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
> +{
> + u32 ports_available;
> +
> + ports_available = 0x0;
Why not make it an initializer? And why do you need the variable at all?
> +
> + pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
> + cpu_to_le32(ports_available));
cpu_to_le32() not needed.
> +
> + pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
> + cpu_to_le32(ports_available));
> +}
> +EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
> +
> /**
> * PCI Quirks for xHCI.
> *
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: g_serial and cdc_acm communications
Can anyone help me with this? How my application should detect device plugout/plugin and SET_CONFIGURATION events? Is my current solution of generating input event on SET_CONFIGURATION call for application to close and reopen device node is Okay? Appreciate any help on this. Regards, Dipen Patel -- 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] xhci: provide usb_disable_xhci_ports function for Intel chipsets.
Some devices with Intel Panther Point chipset may require switchover
usb ports from XHCI back to EHCI controller before shutdown.
Overwise various BIOS bugs related to power management may be
triggered.
Signed-off-by: Denis Turischev
---
drivers/usb/host/pci-quirks.c | 14 ++
drivers/usb/host/pci-quirks.h |1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index df0828c..b19a84a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -800,6 +800,20 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
}
EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
+{
+ u32 ports_available;
+
+ ports_available = 0x0;
+
+ pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
+ cpu_to_le32(ports_available));
+
+ pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
+ cpu_to_le32(ports_available));
+}
+EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+
/**
* PCI Quirks for xHCI.
*
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index b1002a8..ef004a5 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev);
void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
#else
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] xhci: EHCI/XHCI ports switching on Intense-PC.
Intense-PC is Compulab's mini-desktop with Intel Panther Point
chipset.
Unconditional switchover to xHCI provided by function
usb_enable_xhci_ports() leads to surprising results, after shutdown
system powered-on again after a few seconds. On Windows power
related problems were not observed. Switching back to EHCI solves
the problem.
The patch switches usb ports back to EHCI during xhci shutdown
for Intense-PC.
Signed-off-by: Denis Turischev
---
drivers/usb/host/xhci.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index a979cd0..541efaa 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include "pci-quirks.h"
#include "xhci.h"
@@ -656,8 +658,20 @@ void xhci_stop(struct usb_hcd *hcd)
*/
void xhci_shutdown(struct usb_hcd *hcd)
{
+ struct pci_dev *pdev;
+ const char *brd_name;
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ pdev = to_pci_dev(hcd->self.controller);
+
+ if (usb_is_intel_switchable_xhci(pdev)) {
+ brd_name = dmi_get_system_info(DMI_BOARD_NAME);
+
+ /* quirk for Compulab's Intense-PC board */
+ if (brd_name && strstr(brd_name, "Intense-PC"))
+ usb_disable_xhci_ports(pdev);
+ }
+
spin_lock_irq(&xhci->lock);
xhci_halt(xhci);
spin_unlock_irq(&xhci->lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
On Mon, Jul 23, 2012 at 02:21:06PM +0300, Felipe Balbi wrote: > On Mon, Jul 23, 2012 at 07:13:52PM +0800, Richard Zhao wrote: > > On Mon, Jul 23, 2012 at 01:51:55PM +0300, Felipe Balbi wrote: > > > On Mon, Jul 23, 2012 at 11:30:18AM +0200, Marc Kleine-Budde wrote: > > > > On 07/23/2012 11:27 AM, Richard Zhao wrote: > > > > >> This patch looks like a recipe for disaster IMHO, but it's Alex's > > > > >> call. > > > > > Well, if there's any better place to hold it, I'd like to move there. > > > > > Another place is arch/arm/mach-imx. Sascha/Shawn who are maintainers > > > > > of > > > > > imx are also in cc list. > > > > > > > > IMHO it's not about the place where the driver is located, it's about > > > > the shortcomings Michael and Sascha mentioned. > > Thanks, Marc. > > > > > > exactly. It's not about where a file is placed or how it's called. It's > > > how you decided to implement it. This will prevent a platform with > > > multiple instances of the IP to be used, at least. > > To me, usbmisc on imx6 is just a set of non-core registers which is > > companion of Chipidea IP cores. All cores share the same usbmisc. > > From design perspective, ci13xxx_imx knows nothing about usbmisc. It > > just call the ops in proper occasion. usbmisc driver wrappers all > > SoC specific things. > > but if all you need is to call and initialization function, why don't > you just do it on probe() of that usbmisc stuff ? Is this usbmisc used > only for this USB IP ? If it only need to init once, it may follow that way. But it also have remote wakeup enable/disable bits, which in Freescale internal driver, are set enabled or disabled at runtime. Thanks Richard > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: plusb: Add support for PL-2501
From: Mikhail Peselnik
This patch adds support for PL-2501 by adding the appropriate USB
ID's. This chip is used in several USB 'Easy Trasfer' Cables.
Signed-off-by: Mikhail Peselnik
Tested-by: Mikhail Peselnik
---
Now with proper sign-offs and right people in cc and unwrapped lines.
plusb driver (drivers/net/usb/plusb.c) doesn't recognize PL2501 chip.
Since PL2501 uses the same code as PL2301/PL2302 (PL2501 works in
compatibility mode with PL2301/PL2302), the fix is trivial and
attached as a patch.
Just to note: the patch is not mine, it can be found here and there on
Internet.
I've tested the patch and it works great.
Thank you.
--- linux-3.5/drivers/net/usb/plusb.c.orig 2012-07-22 21:06:41.905802795
+0400
+++ linux-3.5/drivers/net/usb/plusb.c 2012-07-22 21:07:00.345552404 +0400
@@ -107,7 +107,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_infoprolific_info = {
- .description = "Prolific PL-2301/PL-2302/PL-25A1",
+ .description = "Prolific PL-2301/PL-2302/PL-25A1/PL-2501",
.flags =FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset =pl_reset,
@@ -139,6 +139,9 @@ static const struct usb_device_id produc
}, {
USB_DEVICE(0x050d, 0x258a), /* Belkin F5U258/F5U279 (PL-25A1) */
.driver_info = (unsigned long) &prolific_info,
+}, {
+ USB_DEVICE(0x067b, 0x2501), /* PL-2501 */
+ .driver_info = (unsigned long) &prolific_info,
},
{ },// END
@@ -158,5 +161,5 @@ static struct usb_driver plusb_driver =
module_usb_driver(plusb_driver);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/2501 USB Host to Host Link
Driver");
MODULE_LICENSE("GPL");
--
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] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Mon, Jul 23, 2012 at 2:03 PM, Roger Quadros wrote: > Hi, > > On 06/22/2012 05:43 PM, Munegowda, Keshava wrote: >> On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman wrote: >>> "Munegowda, Keshava" writes: >>> >>> [...] >>> > >>> >>> You are not reading what I write. >>> >>> To repeat: your patch fixes the oops during boot, and the suspend hang >>> and now I see CORE hit retention in *suspend*. >> >> thanks ! >> >>> >>> However, CORE does still not hit retention during *idle*. >> >> here is the problem. >> >> usb host retention in idle is not supported till now. >> in current code, usb host cuts clock only in driver suspend not in bus >> suspend ( auto suspend). >> usb host driver need to use the io daisy chain framework through io wakeup. >> I will post the patches once ehci remote wakeup features stabilized in >> omap3, omap4 and omap5 too. >> > > We are talking about CORE retention support during idle. How is IO daisy > chaining related to that? Doesn't IO daisy chain only apply when device > hits OFF? when we see the usb bus suspend, then we disable the clocks of usb host to enable to enable the retention in cpu idle; since we have disabled the clock of usb host , we will not see the device connection at the controller level, instead the irq chain handler can detect it and corresponding irq can set the clocks. this same use case holds good for device OFF too. regards keshava -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
On Mon, Jul 23, 2012 at 07:13:52PM +0800, Richard Zhao wrote: > On Mon, Jul 23, 2012 at 01:51:55PM +0300, Felipe Balbi wrote: > > On Mon, Jul 23, 2012 at 11:30:18AM +0200, Marc Kleine-Budde wrote: > > > On 07/23/2012 11:27 AM, Richard Zhao wrote: > > > >> This patch looks like a recipe for disaster IMHO, but it's Alex's call. > > > > Well, if there's any better place to hold it, I'd like to move there. > > > > Another place is arch/arm/mach-imx. Sascha/Shawn who are maintainers of > > > > imx are also in cc list. > > > > > > IMHO it's not about the place where the driver is located, it's about > > > the shortcomings Michael and Sascha mentioned. > Thanks, Marc. > > > > exactly. It's not about where a file is placed or how it's called. It's > > how you decided to implement it. This will prevent a platform with > > multiple instances of the IP to be used, at least. > To me, usbmisc on imx6 is just a set of non-core registers which is > companion of Chipidea IP cores. All cores share the same usbmisc. > From design perspective, ci13xxx_imx knows nothing about usbmisc. It > just call the ops in proper occasion. usbmisc driver wrappers all > SoC specific things. but if all you need is to call and initialization function, why don't you just do it on probe() of that usbmisc stuff ? Is this usbmisc used only for this USB IP ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
On Mon, Jul 23, 2012 at 01:51:55PM +0300, Felipe Balbi wrote: > On Mon, Jul 23, 2012 at 11:30:18AM +0200, Marc Kleine-Budde wrote: > > On 07/23/2012 11:27 AM, Richard Zhao wrote: > > >> This patch looks like a recipe for disaster IMHO, but it's Alex's call. > > > Well, if there's any better place to hold it, I'd like to move there. > > > Another place is arch/arm/mach-imx. Sascha/Shawn who are maintainers of > > > imx are also in cc list. > > > > IMHO it's not about the place where the driver is located, it's about > > the shortcomings Michael and Sascha mentioned. Thanks, Marc. > > exactly. It's not about where a file is placed or how it's called. It's > how you decided to implement it. This will prevent a platform with > multiple instances of the IP to be used, at least. To me, usbmisc on imx6 is just a set of non-core registers which is companion of Chipidea IP cores. All cores share the same usbmisc. >From design perspective, ci13xxx_imx knows nothing about usbmisc. It just call the ops in proper occasion. usbmisc driver wrappers all SoC specific things. > > Also, if that set of registers are shared, you ought to have a dedicated > driver to handle mutual exclusion and so on. Only usbmisc driver access the registers, but maybe called from different Chipidea devices. So it has a spinlock to protect register access. > I don't know details about > the i.MX platform, that really smells funny by looking at it. Thanks Richard > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] usb: dwc3: fix for Link Layer Compliance Suite TD7.06
On Mon, Jul 23, 2012 at 12:56:02PM +0300, Felipe Balbi wrote: > Hi guys, > > So, this is why I have been mostly silent during last week. We were debugging > this failure with the TD7.06 of the Link Layer Compliance Suite - a mandatory > test for USB3 certification - and it turned out to be a silicon issue. > > The workaround is somwhat simple - don't use on-demand transfers for > data phase - but the outcome of that is a rather big rework of ep0 handling, > because we now need to be careful about starting control_data transfers > while still maintaining XferNotReady(DATA) handling for the error condition. > > It took a while to make sure everything was still as stable as before, but > after these patches TI's OMAP5 is passing all USB3 Certification tests (that > includes the entire USB2 test-suite which is mandatory for USB3 devices). > > Please give it a good round of test on your platforms, I will queue this > for v3.7 merge window. Note that I reserve the benefit of still rebasing > these patches until we get -rc1, but I might need to rebase dwc3 again > after that in order to avoid conflicts with Greg's usb-next. This will > happen only during this cycle because I want to make sure we don't get auto- > merge mistakes and end up breaking ep0 handling. > > Now that we have a certifiable solution, we plan to mantain it that way, so > before sending any patches for drivers/usb/dwc3, or > drivers/usb/gadget/composite.c > or drivers/usb/gadget/udc-core.c, make sure to run at leat USB30CV and USB20CV > on your platform. Ideally, you should also pass all Lecroy's test-suite, > including > the extra assertions provided by Lecroy itself as they provide good confidence > that your patch works properly. BTW, these patches are merged on top of my master branch if you want an easy setup to test. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH for v3.5 0/2] usb: gadget: at91_udc: fix oops regression
On Fri, Jul 20, 2012 at 10:33:24AM +0200, Fabio Porcedda wrote: > On Fri, Jul 20, 2012 at 12:50 AM, Greg Kroah-Hartman > wrote: > > On Thu, Jul 19, 2012 at 07:16:54PM +0200, Sebastian Andrzej Siewior wrote: > >> On Thu, Jul 19, 2012 at 03:50:54PM +0200, Fabio Porcedda wrote: > >> > > I would prefer to fix the bug causing the oops instead of reverting > >> > > patches. > >> > > >> > Me too, it's just that i don't have much time to work on that, and so > >> > I'm not confident to be able to fix the kernel panic oops in time for > >> > the v3.5 release. > >> Yes. If nobody looks into this then the v3.5 kernel will be released and > >> other > >> kernels will follow. > >> Would you now please test it and say that it works with those two patches I > >> just posted? > > The patches fix both issues, now the driver works again! please then resend with all acks and a Cc: sta...@vger.kernel.org so I can queue it when -rc1 is tagged. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
On Mon, Jul 23, 2012 at 11:30:18AM +0200, Marc Kleine-Budde wrote: > On 07/23/2012 11:27 AM, Richard Zhao wrote: > >> This patch looks like a recipe for disaster IMHO, but it's Alex's call. > > Well, if there's any better place to hold it, I'd like to move there. > > Another place is arch/arm/mach-imx. Sascha/Shawn who are maintainers of > > imx are also in cc list. > > IMHO it's not about the place where the driver is located, it's about > the shortcomings Michael and Sascha mentioned. exactly. It's not about where a file is placed or how it's called. It's how you decided to implement it. This will prevent a platform with multiple instances of the IP to be used, at least. Also, if that set of registers are shared, you ought to have a dedicated driver to handle mutual exclusion and so on. I don't know details about the i.MX platform, that really smells funny by looking at it. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/1] usb: gadget: s3c-hsotg: fix core reset timeout failure
Hi, On Wed, Jul 04, 2012 at 10:50:30AM +0800, Du, Changbin wrote: > The timeout values were 1000 and timeout issue occurred many times on my > > s3c6410 Soc based board (mostly when booting with USB cable not > > connected). This patch increase the values to 1 to guarantee the > > success of reset. > > > > Having set timeout to 1, I printed the remained timeout values > > which can cause timeout issue before this change (tested several times): > > the first timeout value remained: > > timeout = 8079 > > timeout = 8079 > > timeout = 8078 > > timeout = 8081 > > the second timeout value remained: > > timeout = 7940 > > timeout = 7945 > > timeout = 7940 > > timeout = 7938 > > Seeing from above values, I think 1 is big enough. > > > > Signed-off-by: Du, Changbin changbin...@gmail.com > > --- > > Changes for v2: > > Fixed wrapped line done by my mail client now it' s even worse. Please use git send-email instead. -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function
Hi,
On Thu, Jul 05, 2012 at 08:16:54PM +0300, Ruslan Bilovol wrote:
> Hi,
>
> On Tue, Jul 3, 2012 at 7:13 PM, Felipe Balbi wrote:
> >
> > Hi,
> >
> > On Mon, Jul 02, 2012 at 08:10:49PM +0300, Ruslan Bilovol wrote:
> > > Hi,
> > >
> > >
> > > On Mon, Jul 2, 2012 at 11:13 AM, Felipe Balbi wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Tue, Jun 12, 2012 at 08:36:21PM +0300, Ruslan Bilovol wrote:
> > > > > If the clocks are enabled and we want to enable them again
> > > > > omap4430_phy_set_clk disables them.
> > > > >
> > > > > Fix this - so now if we try to enable already enabled clocks
> > > > > it works correctly.
> > > > >
> > > > > Signed-off-by: Ruslan Bilovol
> > > > > ---
> > > > > arch/arm/mach-omap2/omap_phy_internal.c |2 +-
> > > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
> > > > > b/arch/arm/mach-omap2/omap_phy_internal.c
> > > > > index 4c90477..0196683 100644
> > > > > --- a/arch/arm/mach-omap2/omap_phy_internal.c
> > > > > +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> > > > > @@ -97,7 +97,7 @@ int omap4430_phy_set_clk(struct device *dev, int
> > > > > on)
> > > > > clk_enable(clk48m);
> > > > > clk_enable(clk32k);
> > > > > state = 1;
> > > > > - } else if (state) {
> > > > > + } else if (!on && state) {
> > > >
> > > > why don't you let clocks be enabled twice then ? That would cut down
> > > > the
> > > > churn.
> > >
> > > Currently we have unbalanced call of this function.
> > > I meet first during musb initialization - it tries to disable the phy
> > > that leads to disabling already disabled clocks.
> > > Next goal is to use internal clocks counter and to throw static
> > > variable 'state'.
> >
> > don't even go that way... what you need is to fix the unbalanced calls
> > instead of hacking around some generic API.
>
> Okay Felipe, I understand your position and agree with you. However,
> right now the 'hack' that I'm fixing works incorrectly.
> So while we do not have replacement of the 'hack', it will be good to
> have at least fixed version of this 'hack'.
the problem is that once it "works" nobody ever looks into this again.
So, sorry but I can't accept anything other than a real fix
--
balbi
signature.asc
Description: Digital signature
Re: otg: sharing resources between host and gadget
Thanks for the answer, Peter. As far as I understand You are talking about the second variant when new device is registered / unregistred. How about suspend/resume variant? Is it possible to report -ESHUTDOWN if otg works as a gadget but libusb is trying to access a host or may be bus should be emulated with only roothub on it but not taking control over the bus ? Or suspend/resume should not be used for the otg ? On Mon, Jul 23, 2012 at 2:17 PM, Peter Stuge wrote: > Valentin Sitdikov wrote: >> How should user-space applications handle possibility of switching >> between host and gadget mode (for example libusb if controller is >> working as gadget ?) > > When switching from host mode libusb simply sees that the other > device has disconnected, and libusb is not aware of any gadget > connection that takes it's place. > > The libusb API is so far only for host applications. Feel free to > suggest API additions which would be helpful for you. As always you > speed things up if you also implement them. > > > //Peter > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: plusb: Add support for PL-2501
Hello.
On 22-07-2012 21:42, kyak wrote:
From: Mikhail Peselnik
This patch adds support for PL-2501 by adding the appropriate USB
ID's. This chip is used in several USB 'Easy Trasfer' Cables.
Signed-off-by: Mikhail Peselnik
Tested-by: Mikhail Peselnik
---
Now with proper sign-offs and right people in cc.
plusb driver (drivers/net/usb/plusb.c) doesn't recognize PL2501 chip.
Since PL2501 uses the same code as PL2301/PL2302 (PL2501 works in
compatibility mode with PL2301/PL2302), the fix is trivial and
attached as a patch.
Just to note: the patch is not mine, it can be found here and there on
Internet.
I've tested the patch and it works great.
Thank you.
--- linux-3.5/drivers/net/usb/plusb.c.orig 2012-07-22
21:06:41.905802795 +0400
+++ linux-3.5/drivers/net/usb/plusb.c 2012-07-22 21:07:00.345552404 +0400
[...]
@@ -158,5 +161,5 @@ static struct usb_driver plusb_driver =
module_usb_driver(plusb_driver);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/2501 USB Host to Host
Link Driver");
Your patch is line wrapped. Seeems easy to fix though...
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] usb:gadget: Refcount for gadget pullup
Hi Felipe,
> Hi Felipe,
>
> > This commit fixes the way gadget's pullup method (wrapped at
> > usb_gadget_connect/disconnect) is called in the udc-core.
> >
> > The composite driver allows correct driver registration, even when
> > it calls the usb_gadget_disconnect method (composite driver is
> > defered for further user space configuration - please look into the
> > description of usb_composite_probe at composite.c - line: 1621)
> >
> > One such example is the CCG (Configurable Composite Gadget) driver
> > (at drivers/staging/ccg), which after its registration has no usb
> > descriptor (i.e. idProduct, idVendor etc.) and functions registered.
> > Those are configured after writing to /sys/module/g_ccg/parameters/
> > or /sys/class/ccg_usb/ccg0/.
> >
> > Unfortunately, the code at 'usb_gadget_probe_driver' method (some
> > code omitted):
> >
> > if (udc_is_newstyle(udc)) {
> > bind(udc->gadget);
> > usb_gadget_udc_start(udc->gadget, driver);
> > usb_gadget_connect(udc->gadget);
> > }
> >
> > Explicitly calls the usb_gadget_connect method for this driver. It
> > looks that the udc-core enables pullup for a driver, which has no
> > functions and no descriptor filled (those values are feed from
> > userspace).
> >
> > The solution (at least until the udc-core is reworked) is to add
> > atomic variable, which helps in balancing the number of called
> > usb_gadget_connect/ disconnect functions.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/usb/gadget/udc-core.c | 17 -
> > include/linux/usb/gadget.h| 13 +++--
> > 2 files changed, 27 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/gadget/udc-core.c
> > b/drivers/usb/gadget/udc-core.c index e5e44f8..a26517e 100644
> > --- a/drivers/usb/gadget/udc-core.c
> > +++ b/drivers/usb/gadget/udc-core.c
> > @@ -349,7 +349,22 @@ found:
> > }
> > usb_gadget_connect(udc->gadget);
> > } else {
> > -
> > + /*
> > +* This is a hack for "old style" gadgets:
> > +*
> > +* The udc_start for "old style" gadgets performs
> > implicitly all
> > +* operations done by usb_gadget_connect(but not
> > calling it).
> > +* Therefore non composite gadgets (like rndis)
> > works even with
> > +* wrong connect_count value ("old style" gadgets
> > don't call
> > +* usb_gadget_connect/disconnect).
> > +*
> > +* On the other hand the CCG (Configurable
> > Composite Gadget)
> > +* requires this incrementation since it calls
> > +* usb_gadget_disconnect on its probe (it is
> > allowed) and hence
> > +* the proper balance is needed when the
> > usb_gadget_connect(i.e.
> > +* pullup) is called, when triggered from userspace
> > event.
> > +*/
> > + atomic_inc(&udc->gadget->connect_count);
> > ret = usb_gadget_start(udc->gadget, driver, bind);
> > if (ret)
> > goto err1;
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index 9517466..0801d83 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -534,6 +534,7 @@ struct usb_gadget {
> > unsignedb_hnp_enable:1;
> > unsigneda_hnp_support:1;
> > unsigneda_alt_hnp_support:1;
> > + atomic_tconnect_count;
> > const char *name;
> > struct device dev;
> > };
> > @@ -739,7 +740,11 @@ static inline int usb_gadget_connect(struct
> > usb_gadget *gadget) {
> > if (!gadget->ops->pullup)
> > return -EOPNOTSUPP;
> > - return gadget->ops->pullup(gadget, 1);
> > +
> > + if (atomic_inc_return(&gadget->connect_count) == 1)
> > + return gadget->ops->pullup(gadget, 1);
> > +
> > + return 0;
> > }
> >
> > /**
> > @@ -761,7 +766,11 @@ static inline int usb_gadget_disconnect(struct
> > usb_gadget *gadget) {
> > if (!gadget->ops->pullup)
> > return -EOPNOTSUPP;
> > - return gadget->ops->pullup(gadget, 0);
> > +
> > + if (atomic_dec_and_test(&gadget->connect_count))
> > + return gadget->ops->pullup(gadget, 0);
> > +
> > + return 0;
> > }
> >
> >
>
> Any thoughts about solving this problem?
>
Felipe, can you look into this problem?
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
--
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: otg: sharing resources between host and gadget
Valentin Sitdikov wrote: > How should user-space applications handle possibility of switching > between host and gadget mode (for example libusb if controller is > working as gadget ?) When switching from host mode libusb simply sees that the other device has disconnected, and libusb is not aware of any gadget connection that takes it's place. The libusb API is so far only for host applications. Feel free to suggest API additions which would be helpful for you. As always you speed things up if you also implement them. //Peter -- 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 8/9] usb: dwc3: ep0: fix status phase delayed status direction
commit 68d3e66 (usb: dwc3: ep0: fix for possible early
delayed_status) added handling for early delayed status,
but the current code only works because so far delayed
status will always be on the IN direction.
This patch makes the code more robust by making sure that
we can handle all directions properly.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 3936c64..3f2c698 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -164,10 +164,13 @@ static int __dwc3_gadget_ep0_queue(struct dwc3_ep *dep,
* handle it here.
*/
if (dwc->delayed_status) {
+ unsigneddirection;
+
+ direction = !dwc->ep0_expect_in;
dwc->delayed_status = false;
if (dwc->ep0state == EP0_STATUS_PHASE)
- __dwc3_ep0_do_control_status(dwc, dwc->eps[1]);
+ __dwc3_ep0_do_control_status(dwc, dwc->eps[direction]);
else
dev_dbg(dwc->dev, "too early for delayed status\n");
--
1.7.11
--
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 9/9] usb: dwc3: ep0: make sure to reinitilize ep1 on STALL
When issuing SetStall on ep0, we must make sure to
reinitialize all flags on physical ep1 too.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 3f2c698..1bba97b 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -262,9 +262,14 @@ out:
static void dwc3_ep0_stall_and_restart(struct dwc3 *dwc)
{
- struct dwc3_ep *dep = dwc->eps[0];
+ struct dwc3_ep *dep;
+
+ /* reinitialize physical ep1 */
+ dep = dwc->eps[1];
+ dep->flags = DWC3_EP_ENABLED;
/* stall is always issued on EP0 */
+ dep = dwc->eps[0];
__dwc3_gadget_ep_set_halt(dep, 1);
dep->flags = DWC3_EP_ENABLED;
dwc->delayed_status = false;
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] usb: dwc3: ep0: ignore XferNotReady(STATUS) when we're not expecting it
Databook doesn't say we should stall if we
get XferNotReady(STATUS) while we're expecting
something else.
Instead of stalling and restarting, tests have
proven that ignoring the event is far more
effective.
This problem has been caught while rewriting
ep0 handling in order we pass Link Layer TD7.6.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index d4b38c7..39abc58 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -953,19 +953,13 @@ static void dwc3_ep0_xfernotready(struct dwc3 *dwc,
break;
case DEPEVT_STATUS_CONTROL_STATUS:
+ if (dwc->ep0_next_event != DWC3_EP0_NRDY_STATUS)
+ return;
+
dev_vdbg(dwc->dev, "Control Status\n");
dwc->ep0state = EP0_STATUS_PHASE;
- if (dwc->ep0_next_event != DWC3_EP0_NRDY_STATUS) {
- dev_vdbg(dwc->dev, "Expected %d got %d\n",
- dwc->ep0_next_event,
- DWC3_EP0_NRDY_STATUS);
-
- dwc3_ep0_stall_and_restart(dwc);
- return;
- }
-
if (dwc->delayed_status) {
WARN_ON_ONCE(event->endpoint_number != 1);
dev_vdbg(dwc->dev, "Mass Storage delayed status\n");
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] usb: dwc3: ep0: move DATA phase away from on-demand
We uncovered a limitation of this core WRT to the
Link Layer Compliance Suite's TD7.06.
On that test, host will start a GetDescriptor(DEVICE)
standard request, but it will do so only on the
SETUP phase, meaning there will *NOT* be any DATA or
STATUS phases.
The idea of the test is to verify robustness of the
IP WRT framing errors, so the test will send a
sequence of different SETUP_DPs each with a different
framing error and the Suite expects us to be able to
receive all SETUP_DPs with no timeouts.
This core, has the ability to tell us which phase the
host is expecting before we start it. Whenever we
receive a TP or DP when no transfers are cached on
the internal IP's caches, the IP will generate a
XferNotReady event with status informing us (in case
of physical ep0/ep1) if it's related to DATA or STATUS
phases - SETUP phase is expected to be prestarted.
Because we're always waiting for XferNotReady
events for DATA and STATUS phases, we will never
be able to know that the Host wants to start another
SETUP phase instead, which will render us "not
compliant" with TD7.06.
In order to "fix" the problem we must not rely
on XferNotReady events for the DATA phase and try
to always pre-start DATA transfers on physical
endpoints 0 and 1. If host goes back to SETUP phase
from DATA phase we will receive a XferComplete for
that phase with TRB's status set to SETUP_PENDING,
which is only useful for printing a debugging log as
the core expects us to still go through to the STATUS
phase, initiate a CONTROL_STATUS TRB just so it
completes right away and, only then, we go back to
the pending SETUP phase.
SNPS has decided to modify the programming model of
the core so that on-demand DATA phases will not be
supported anymore. Note that this limitation does not
affect 2-stage transfers, meaning that if TD7.06 would
start a 2-stage transfer instead of a 3-stage transfer,
we would receive a "fake" XferNotReady(STATUS) which
would complete right after being initiated with
SETUP_PENDING status.
Other endpoints are also not affected, so we can still
use on-demand transfers on Bulk/Isoc/Interrupt endpoints.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 39abc58..69d5741 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -174,6 +174,49 @@ static int __dwc3_gadget_ep0_queue(struct dwc3_ep *dep,
return 0;
}
+ /*
+* Unfortunately we have uncovered a limitation wrt the Data Phase.
+*
+* Section 9.4 says we can wait for the XferNotReady(DATA) event to
+* come before issueing Start Transfer command, but if we do, we will
+* miss situations where the host starts another SETUP phase instead of
+* the DATA phase. Such cases happen at least on TD.7.6 of the Link
+* Layer Compliance Suite.
+*
+* The problem surfaces due to the fact that in case of back-to-back
+* SETUP packets there will be no XferNotReady(DATA) generated and we
+* will be stuck waiting for XferNotReady(DATA) forever.
+*
+* By looking at tables 9-13 and 9-14 of the Databook, we can see that
+* it tells us to start Data Phase right away. It also mentions that if
+* we receive a SETUP phase instead of the DATA phase, core will issue
+* XferComplete for the DATA phase, before actually initiating it in
+* the wire, with the TRB's status set to "SETUP_PENDING". Such status
+* can only be used to print some debugging logs, as the core expects
+* us to go through to the STATUS phase and start a CONTROL_STATUS TRB,
+* just so it completes right away, without transferring anything and,
+* only then, we can go back to the SETUP phase.
+*
+* Because of this scenario, SNPS decided to change the programming
+* model of control transfers and support on-demand transfers only for
+* the STATUS phase. To fix the issue we have now, we will always wait
+* for gadget driver to queue the DATA phase's struct usb_request, then
+* start it right away.
+*
+* If we're actually in a 2-stage transfer, we will wait for
+* XferNotReady(STATUS).
+*/
+ if (dwc->three_stage_setup) {
+ unsigneddirection;
+
+ direction = dwc->ep0_expect_in;
+ dwc->ep0state = EP0_DATA_PHASE;
+
+ __dwc3_ep0_do_control_data(dwc, dwc->eps[direction], req);
+
+ dep->flags &= ~DWC3_EP0_DIR_IN;
+ }
+
return 0;
}
@@ -707,6 +750,7 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
struct dwc3_trb *trb;
struct dwc3_ep *ep0;
u32 transferred;
+ u32 status;
u32
[PATCH 7/9] usb: dwc3: ep0: drop XferNotReady(DATA) support
Due to the late Silicon limitation found, we are
now pre-starting DATA phase's TRBs. If, still, we
get XferNotReady(DATA) we will ignore it unless
we're getting it for the wrong direction.
In that case we must keep the error case handling
plus add a ENDTRANSFER command to forcefully end
the Data TRB we started previously, then continue
to SetStall and so on.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 67 --
1 file changed, 27 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 69d5741..3936c64 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -923,29 +923,6 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
WARN_ON(ret < 0);
}
-static void dwc3_ep0_do_control_data(struct dwc3 *dwc,
- const struct dwc3_event_depevt *event)
-{
- struct dwc3_ep *dep;
- struct dwc3_request *req;
-
- dep = dwc->eps[0];
-
- if (list_empty(&dep->request_list)) {
- dev_vdbg(dwc->dev, "pending request for EP0 Data phase\n");
- dep->flags |= DWC3_EP_PENDING_REQUEST;
-
- if (event->endpoint_number)
- dep->flags |= DWC3_EP0_DIR_IN;
- return;
- }
-
- req = next_request(&dep->request_list);
- dep = dwc->eps[event->endpoint_number];
-
- __dwc3_ep0_do_control_data(dwc, dep, req);
-}
-
static int dwc3_ep0_start_control_status(struct dwc3_ep *dep)
{
struct dwc3 *dwc = dep->dwc;
@@ -977,6 +954,24 @@ static void dwc3_ep0_do_control_status(struct dwc3 *dwc,
__dwc3_ep0_do_control_status(dwc, dep);
}
+static void dwc3_ep0_end_control_data(struct dwc3 *dwc, struct dwc3_ep *dep)
+{
+ struct dwc3_gadget_ep_cmd_params params;
+ u32 cmd;
+ int ret;
+
+ if (!dep->resource_index)
+ return;
+
+ cmd = DWC3_DEPCMD_ENDTRANSFER;
+ cmd |= DWC3_DEPCMD_CMDIOC;
+ cmd |= DWC3_DEPCMD_PARAM(dep->resource_index);
+ memset(¶ms, 0, sizeof(params));
+ ret = dwc3_send_gadget_ep_cmd(dwc, dep->number, cmd, ¶ms);
+ WARN_ON_ONCE(ret);
+ dep->resource_index = 0;
+}
+
static void dwc3_ep0_xfernotready(struct dwc3 *dwc,
const struct dwc3_event_depevt *event)
{
@@ -986,32 +981,24 @@ static void dwc3_ep0_xfernotready(struct dwc3 *dwc,
case DEPEVT_STATUS_CONTROL_DATA:
dev_vdbg(dwc->dev, "Control Data\n");
- dwc->ep0state = EP0_DATA_PHASE;
-
- if (dwc->ep0_next_event != DWC3_EP0_NRDY_DATA) {
- dev_vdbg(dwc->dev, "Expected %d got %d\n",
- dwc->ep0_next_event,
- DWC3_EP0_NRDY_DATA);
-
- dwc3_ep0_stall_and_restart(dwc);
- return;
- }
-
/*
-* One of the possible error cases is when Host _does_
-* request for Data Phase, but it does so on the wrong
-* direction.
+* We already have a DATA transfer in the controller's cache,
+* if we receive a XferNotReady(DATA) we will ignore it, unless
+* it's for the wrong direction.
*
-* Here, we already know ep0_next_event is DATA (see above),
-* so we only need to check for direction.
+* In that case, we must issue END_TRANSFER command to the Data
+* Phase we already have started and issue SetStall on the
+* control endpoint.
*/
if (dwc->ep0_expect_in != event->endpoint_number) {
+ struct dwc3_ep *dep = dwc->eps[dwc->ep0_expect_in];
+
dev_vdbg(dwc->dev, "Wrong direction for Data phase\n");
+ dwc3_ep0_end_control_data(dwc, dep);
dwc3_ep0_stall_and_restart(dwc);
return;
}
- dwc3_ep0_do_control_data(dwc, event);
break;
case DEPEVT_STATUS_CONTROL_STATUS:
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] usb: dwc3: ep0: drop dead code
There's no such thing as XferNotReady(SETUP), we
can safely drop all that code with no problems
whatsoever.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 2 --
drivers/usb/dwc3/ep0.c | 49 -
2 files changed, 51 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 151eca8..c611d80 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -457,7 +457,6 @@ enum dwc3_phy {
enum dwc3_ep0_next {
DWC3_EP0_UNKNOWN = 0,
DWC3_EP0_COMPLETE,
- DWC3_EP0_NRDY_SETUP,
DWC3_EP0_NRDY_DATA,
DWC3_EP0_NRDY_STATUS,
};
@@ -779,7 +778,6 @@ struct dwc3_event_depevt {
#define DEPEVT_STREAMEVT_NOTFOUND 2
/* Control-only Status */
-#define DEPEVT_STATUS_CONTROL_SETUP0
#define DEPEVT_STATUS_CONTROL_DATA 1
#define DEPEVT_STATUS_CONTROL_STATUS 2
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 28bce9b..d4b38c7 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -809,12 +809,6 @@ static void dwc3_ep0_xfer_complete(struct dwc3 *dwc,
}
}
-static void dwc3_ep0_do_control_setup(struct dwc3 *dwc,
- const struct dwc3_event_depevt *event)
-{
- dwc3_ep0_out_start(dwc);
-}
-
static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
struct dwc3_ep *dep, struct dwc3_request *req)
{
@@ -926,50 +920,7 @@ static void dwc3_ep0_xfernotready(struct dwc3 *dwc,
{
dwc->setup_packet_pending = true;
- /*
-* This part is very tricky: If we have just handled
-* XferNotReady(Setup) and we're now expecting a
-* XferComplete but, instead, we receive another
-* XferNotReady(Setup), we should STALL and restart
-* the state machine.
-*
-* In all other cases, we just continue waiting
-* for the XferComplete event.
-*
-* We are a little bit unsafe here because we're
-* not trying to ensure that last event was, indeed,
-* XferNotReady(Setup).
-*
-* Still, we don't expect any condition where that
-* should happen and, even if it does, it would be
-* another error condition.
-*/
- if (dwc->ep0_next_event == DWC3_EP0_COMPLETE) {
- switch (event->status) {
- case DEPEVT_STATUS_CONTROL_SETUP:
- dev_vdbg(dwc->dev, "Unexpected XferNotReady(Setup)\n");
- dwc3_ep0_stall_and_restart(dwc);
- break;
- case DEPEVT_STATUS_CONTROL_DATA:
- /* FALLTHROUGH */
- case DEPEVT_STATUS_CONTROL_STATUS:
- /* FALLTHROUGH */
- default:
- dev_vdbg(dwc->dev, "waiting for XferComplete\n");
- }
-
- return;
- }
-
switch (event->status) {
- case DEPEVT_STATUS_CONTROL_SETUP:
- dev_vdbg(dwc->dev, "Control Setup\n");
-
- dwc->ep0state = EP0_SETUP_PHASE;
-
- dwc3_ep0_do_control_setup(dwc, event);
- break;
-
case DEPEVT_STATUS_CONTROL_DATA:
dev_vdbg(dwc->dev, "Control Data\n");
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] usb: dwc3: ep0: split the special cases on ep0_queue
We can return early from each if () branch
and split the special cases for clarity. While
at that also add a comment to the delayed_status
case.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 962fb9b..28bce9b 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -155,13 +155,23 @@ static int __dwc3_gadget_ep0_queue(struct dwc3_ep *dep,
dep->flags &= ~(DWC3_EP_PENDING_REQUEST |
DWC3_EP0_DIR_IN);
- } else if (dwc->delayed_status) {
+
+ return 0;
+ }
+
+ /*
+* In case gadget driver asked us to delay the STATUS phase,
+* handle it here.
+*/
+ if (dwc->delayed_status) {
dwc->delayed_status = false;
if (dwc->ep0state == EP0_STATUS_PHASE)
__dwc3_ep0_do_control_status(dwc, dwc->eps[1]);
else
dev_dbg(dwc->dev, "too early for delayed status\n");
+
+ return 0;
}
return 0;
--
1.7.11
--
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/9] usb: dwc3: ep0: drop unnecessary variable
When returning from ep0_queue, we have an
unnecessary ret variable which is always
zero. Remove it.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/ep0.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 9b94886..962fb9b 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -125,7 +125,6 @@ static int __dwc3_gadget_ep0_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
{
struct dwc3 *dwc = dep->dwc;
- int ret = 0;
req->request.actual = 0;
req->request.status = -EINPROGRESS;
@@ -165,7 +164,7 @@ static int __dwc3_gadget_ep0_queue(struct dwc3_ep *dep,
dev_dbg(dwc->dev, "too early for delayed status\n");
}
- return ret;
+ return 0;
}
int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct usb_request *request,
--
1.7.11
--
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/9] usb: dwc3: gadget: set Ignore Sequence Number bit from ConnectDone Event
Databook says we should set Ignore Sequence Number bit
from ConnectDone Event, so let's do so.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 58fdfad..283c0cb 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -431,7 +431,8 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc,
struct dwc3_ep *dep)
static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep,
const struct usb_endpoint_descriptor *desc,
- const struct usb_ss_ep_comp_descriptor *comp_desc)
+ const struct usb_ss_ep_comp_descriptor *comp_desc,
+ bool ignore)
{
struct dwc3_gadget_ep_cmd_params params;
@@ -441,6 +442,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
struct dwc3_ep *dep,
| DWC3_DEPCFG_MAX_PACKET_SIZE(usb_endpoint_maxp(desc))
| DWC3_DEPCFG_BURST_SIZE(dep->endpoint.maxburst - 1);
+ if (ignore)
+ params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM;
+
params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN
| DWC3_DEPCFG_XFER_NOT_READY_EN;
@@ -498,7 +502,8 @@ static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc,
struct dwc3_ep *dep)
*/
static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
const struct usb_endpoint_descriptor *desc,
- const struct usb_ss_ep_comp_descriptor *comp_desc)
+ const struct usb_ss_ep_comp_descriptor *comp_desc,
+ bool ignore)
{
struct dwc3 *dwc = dep->dwc;
u32 reg;
@@ -510,7 +515,7 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
return ret;
}
- ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc);
+ ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc, ignore);
if (ret)
return ret;
@@ -683,7 +688,7 @@ static int dwc3_gadget_ep_enable(struct usb_ep *ep,
dev_vdbg(dwc->dev, "Enabling %s\n", dep->name);
spin_lock_irqsave(&dwc->lock, flags);
- ret = __dwc3_gadget_ep_enable(dep, desc, ep->comp_desc);
+ ret = __dwc3_gadget_ep_enable(dep, desc, ep->comp_desc, false);
spin_unlock_irqrestore(&dwc->lock, flags);
return ret;
@@ -1518,14 +1523,14 @@ static int dwc3_gadget_start(struct usb_gadget *g,
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512);
dep = dwc->eps[0];
- ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL);
+ ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL, false);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
goto err0;
}
dep = dwc->eps[1];
- ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL);
+ ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL, false);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
goto err1;
@@ -2141,14 +2146,14 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3
*dwc)
}
dep = dwc->eps[0];
- ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL);
+ ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL, true);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
return;
}
dep = dwc->eps[1];
- ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL);
+ ret = __dwc3_gadget_ep_enable(dep, &dwc3_gadget_ep0_desc, NULL, true);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
return;
--
1.7.11
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] usb: dwc3: fix for Link Layer Compliance Suite TD7.06
Hi guys, So, this is why I have been mostly silent during last week. We were debugging this failure with the TD7.06 of the Link Layer Compliance Suite - a mandatory test for USB3 certification - and it turned out to be a silicon issue. The workaround is somwhat simple - don't use on-demand transfers for data phase - but the outcome of that is a rather big rework of ep0 handling, because we now need to be careful about starting control_data transfers while still maintaining XferNotReady(DATA) handling for the error condition. It took a while to make sure everything was still as stable as before, but after these patches TI's OMAP5 is passing all USB3 Certification tests (that includes the entire USB2 test-suite which is mandatory for USB3 devices). Please give it a good round of test on your platforms, I will queue this for v3.7 merge window. Note that I reserve the benefit of still rebasing these patches until we get -rc1, but I might need to rebase dwc3 again after that in order to avoid conflicts with Greg's usb-next. This will happen only during this cycle because I want to make sure we don't get auto- merge mistakes and end up breaking ep0 handling. Now that we have a certifiable solution, we plan to mantain it that way, so before sending any patches for drivers/usb/dwc3, or drivers/usb/gadget/composite.c or drivers/usb/gadget/udc-core.c, make sure to run at leat USB30CV and USB20CV on your platform. Ideally, you should also pass all Lecroy's test-suite, including the extra assertions provided by Lecroy itself as they provide good confidence that your patch works properly. Felipe Balbi (9): usb: dwc3: gadget: set Ignore Sequence Number bit from ConnectDone Event usb: dwc3: ep0: drop unnecessary variable usb: dwc3: ep0: split the special cases on ep0_queue usb: dwc3: ep0: drop dead code usb: dwc3: ep0: ignore XferNotReady(STATUS) when we're not expecting it usb: dwc3: ep0: move DATA phase away from on-demand usb: dwc3: ep0: drop XferNotReady(DATA) support usb: dwc3: ep0: fix status phase delayed status direction usb: dwc3: ep0: make sure to reinitilize ep1 on STALL drivers/usb/dwc3/core.h | 2 - drivers/usb/dwc3/ep0.c| 217 -- drivers/usb/dwc3/gadget.c | 21 +++-- 3 files changed, 127 insertions(+), 113 deletions(-) -- 1.7.11 -- 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
otg: sharing resources between host and gadget
Hello All, Could somebody recommend me what is the standard way to share resources between host and gadget? I have seen at least two implementation: 1. Using suspend/resume: OTG driver resumes or suspends host and device accordingly to otg state (value ID pin for example) 2. Device registration/unregistration: OTG driver registers/unregisters host device accordingly to otg state . What is most preferable way to implement? How should user-space applications handle possibility of switching between host and gadget mode (for example libusb if controller is working as gadget ?) Thanks in advance, Valentin. -- 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: qmi wwan interface does not work in this version 3.5.rc7.next.20120720
[CCing Dan Carpenter as I believe he has reported the NULL pointer dereference on serial device unplug before] Bjørn Mork writes: > "Thomas Schäfer" wrote: > >>This happens with the Huawei E398 (supported since 3.4) >> >> >>dmesg >>[ 133.764128] usb 1-4: new high-speed USB device number 3 using >>ehci_hcd >>[ 133.899087] usb 1-4: New USB device found, idVendor=12d1, >>idProduct=1505 >>[ 133.899102] usb 1-4: New USB device strings: Mfr=3, Product=2, >>SerialNumber=0 >>[ 133.899111] usb 1-4: Product: HUAWEI Mobile >>[ 133.899120] usb 1-4: Manufacturer: Huawei Technologies >>[ 133.959452] usbcore: registered new interface driver uas >>[ 133.969406] Initializing USB Mass Storage driver... >>[ 133.970572] scsi4 : usb-storage 1-4:1.0 >>[ 133.970960] usbcore: registered new interface driver usb-storage >>[ 133.970967] USB Mass Storage support registered. >>[ 134.716146] usb 1-4: USB disconnect, device number 3 >>[ 144.604138] usb 1-4: new high-speed USB device number 4 using >>ehci_hcd >>[ 144.739362] usb 1-4: New USB device found, idVendor=12d1, >>idProduct=1506 >>[ 144.739377] usb 1-4: New USB device strings: Mfr=4, Product=3, >>SerialNumber=0 >>[ 144.739387] usb 1-4: Product: HUAWEI Mobile >>[ 144.739395] usb 1-4: Manufacturer: Huawei Technologies >>[ 144.744396] scsi5 : usb-storage 1-4:1.5 >>[ 144.745587] scsi6 : usb-storage 1-4:1.6 >>[ 144.800200] usbcore: registered new interface driver usbserial >>[ 144.800264] usbcore: registered new interface driver >>usbserial_generic >>[ 144.800309] USB Serial support registered for generic >>[ 144.800325] usbserial: USB Serial Driver core >>[ 144.812227] usbcore: registered new interface driver cdc_wdm >>[ 144.816522] usbcore: registered new interface driver option >>[ 144.816580] USB Serial support registered for GSM modem (1-port) >>[ 144.816821] option 1-4:1.0: GSM modem (1-port) converter detected >>[ 144.817153] usb 1-4: GSM modem (1-port) converter now attached to >>ttyUSB0 >>[ 144.817223] option 1-4:1.1: GSM modem (1-port) converter detected >>[ 144.822070] usb 1-4: GSM modem (1-port) converter now attached to >>ttyUSB1 >>[ 144.822163] option 1-4:1.2: GSM modem (1-port) converter detected >>[ 144.822628] usb 1-4: GSM modem (1-port) converter now attached to >>ttyUSB2 >>[ 144.843517] qmi_wwan 1-4:1.3: cdc-wdm0: USB WDM device >>[ 144.844156] qmi_wwan 1-4:1.3: wwan0: register 'qmi_wwan' at >>usb-:00:1d.7-4, WWAN/QMI device, 00:a0:c6:00:00:00 >>[ 144.844266] usbcore: registered new interface driver qmi_wwan >>[ 145.745563] scsi 5:0:0:0: CD-ROMHUAWEI Mass Storage >> 2.31 PQ: 0 ANSI: 0 >>[ 145.746478] scsi 5:0:0:0: Attached scsi generic sg1 type 5 >>[ 145.749398] scsi 6:0:0:0: Direct-Access HUAWEI SD Storage >> 2.31 PQ: 0 ANSI: 2 >>[ 145.750483] sd 6:0:0:0: Attached scsi generic sg2 type 0 >>[ 145.751473] sd 6:0:0:0: [sdb] 31116288 512-byte logical blocks: >>(15.9 GB/14.8 GiB) >>[ 145.752841] sd 6:0:0:0: [sdb] Write Protect is off >>[ 145.752862] sd 6:0:0:0: [sdb] Mode Sense: 0f 0e 00 00 >>[ 145.753848] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: >>enabled, doesn't support DPO or FUA >>[ 145.762461] sdb: sdb1 >>[ 145.766371] sd 6:0:0:0: [sdb] Attached SCSI removable disk >>[ 145.787558] sr0: scsi-1 drive >>[ 145.787572] cdrom: Uniform CD-ROM driver Revision: 3.20 >>[ 145.789625] sr 5:0:0:0: Attached scsi CD-ROM sr0 >>[ 243.145559] usb 1-4: USB disconnect, device number 4 >>[ 243.147961] option1 ttyUSB0: option_instat_callback: error -108 >>[ 243.148375] option1 ttyUSB0: GSM modem (1-port) converter now >>disconnected from ttyUSB0 >>[ 243.148471] BUG: unable to handle kernel NULL pointer dereference at >> (null) >>[ 243.148508] IP: [] stop_read_write_urbs+0x37/0x80 >>[usb_wwan] >>[ 243.148556] PGD 79d60067 PUD 79d61067 PMD 0 >>[ 243.148590] Oops: [#1] SMP >>[ 243.148617] Modules linked in: sr_mod cdrom qmi_wwan usbnet option >>cdc_wdm usb_wwan usbserial usb_storage uas fuse af_packet >>ip6table_filter ip6_tables iptable_filter ip_tables x_tables tun edd >>cpufreq_conservative cpufreq_userspace cpufreq_powersave snd_pcm_oss >>snd_mixer_oss acpi_cpufreq snd_seq mperf snd_seq_device coretemp arc4 >>sg hp_wmi sparse_keymap uvcvideo videobuf2_core >>videodev videobuf2_vmalloc videobuf2_memops rtl8192ce rtl8192c_common >>rtlwifi joydev pcspkr microcode mac80211 i2c_i801 lpc_ich r8169 >>snd_hda_codec_idt cfg80211 snd_hda_intel snd_hda_codec rfkill >>snd_hwdep snd_pcm wmi snd_timer ac snd soundcore snd_page_alloc battery >>uhci_hcd i915 drm_kms_helper drm i2c_algo_bit ehci_hcd thermal usbcore >>video usb_common button processor thermal_sys >>[ 243.149007] CPU 1 >>[ 243.149027] Pid: 135, comm: khubd Not tainted >>3.5.0-rc7-next-20120720-1-vanilla #1 Hewlett-Packard HP Mini 110-3700 >> /1584 >>[ 243.149072] RIP: 0010:[] [] >>stop_read_write_urbs+0x37/0x80 [usb_wwan] >>[ 243.149118] RSP: 0018:880037e75b30 EFLAGS: 00010286 >>[ 243.14913
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
On 07/23/2012 11:27 AM, Richard Zhao wrote: >> This patch looks like a recipe for disaster IMHO, but it's Alex's call. > Well, if there's any better place to hold it, I'd like to move there. > Another place is arch/arm/mach-imx. Sascha/Shawn who are maintainers of > imx are also in cc list. IMHO it's not about the place where the driver is located, it's about the shortcomings Michael and Sascha mentioned. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
> > This patch looks like a recipe for disaster IMHO, but it's Alex's call. Well, if there's any better place to hold it, I'd like to move there. Another place is arch/arm/mach-imx. Sascha/Shawn who are maintainers of imx are also in cc list. Thanks Richard > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] USB: chipidea: add imx usbmisc support
Hi,
On Wed, Jul 18, 2012 at 06:29:06PM +0800, Richard Zhao wrote:
> i.MX usb controllers shares non-core registers, which may include
> SoC specific controls. We take it as a usbmisc device and usbmisc
> driver set operations needed by ci13xxx_imx driver.
>
> For example, Sabrelite board has bad over-current design, we can
> usbmisc to disable over-current detect.
>
> Signed-off-by: Richard Zhao
> ---
> .../devicetree/bindings/usb/ci13xxx-imx.txt|2 +
> .../devicetree/bindings/usb/usbmisc-imx.txt| 12 ++
> drivers/usb/chipidea/Makefile |2 +-
> drivers/usb/chipidea/ci13xxx_imx.c | 23 +++
> drivers/usb/chipidea/usbmisc_imx6q.c | 161
>
> 5 files changed, 199 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> create mode 100644 drivers/usb/chipidea/usbmisc_imx6q.c
>
> diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
> b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
> index 2c29041..06105ce 100644
> --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
> +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
> @@ -8,6 +8,7 @@ Required properties:
> Optional properties:
> - fsl,usbphy: phandler of usb phy that connects to the only one port
> - vbus-supply: regulator for vbus
> +- disable-over-current: disable over current detect
>
> Examples:
> usb@02184000 { /* USB OTG */
> @@ -15,4 +16,5 @@ usb@02184000 { /* USB OTG */
> reg = <0x02184000 0x200>;
> interrupts = <0 43 0x04>;
> fsl,usbphy = <&usbphy1>;
> + disable-over-current;
> };
> diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> new file mode 100644
> index 000..4fa500d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> @@ -0,0 +1,12 @@
> +* Freescale i.MX non-core registers
> +
> +Required properties:
> +- compatible: Should be one of below:
> + "fsl,imx6q-usbmisc" for imx6q
> +- reg: Should contain registers location and length
> +
> +Examples:
> +usbmisc@02184800 {
> + compatible = "fsl,imx6q-usbmisc";
> + reg = <0x02184800 0x200>;
> +};
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 5c66d9c..57e510f 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -15,5 +15,5 @@ ifneq ($(CONFIG_PCI),)
> endif
>
> ifneq ($(CONFIG_OF_DEVICE),)
> - obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o
> + obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o usbmisc_imx6q.o
> endif
> diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
> b/drivers/usb/chipidea/ci13xxx_imx.c
> index ef60d06..e790c0e 100644
> --- a/drivers/usb/chipidea/ci13xxx_imx.c
> +++ b/drivers/usb/chipidea/ci13xxx_imx.c
> @@ -22,6 +22,7 @@
> #include
>
> #include "ci.h"
> +#include "ci13xxx_imx.h"
>
> #define pdev_to_phy(pdev) \
> ((struct usb_phy *)platform_get_drvdata(pdev))
> @@ -34,6 +35,25 @@ struct ci13xxx_imx_data {
> struct regulator *reg_vbus;
> };
>
> +static const struct usbmisc_ops *usbmisc_ops;
> +
> +int usbmisc_set_ops(const struct usbmisc_ops *ops)
> +{
> + if (usbmisc_ops)
> + return -EBUSY;
> +
> + usbmisc_ops = ops;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usbmisc_set_ops);
> +
> +void usbmisc_unset_ops(const struct usbmisc_ops *ops)
> +{
> + usbmisc_ops = NULL;
> +}
> +EXPORT_SYMBOL_GPL(usbmisc_unset_ops);
> +
> static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata = {
> .name = "ci13xxx_imx",
> .flags = CI13XXX_REQUIRE_TRANSCEIVER |
> @@ -120,6 +140,9 @@ static int __devinit ci13xxx_imx_probe(struct
> platform_device *pdev)
> *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> dma_set_coherent_mask(&pdev->dev, *pdev->dev.dma_mask);
> }
> +
> + usbmisc_ops->init(&pdev->dev);
> +
> plat_ci = ci13xxx_add_device(&pdev->dev,
> pdev->resource, pdev->num_resources,
> &ci13xxx_imx_platdata);
> diff --git a/drivers/usb/chipidea/usbmisc_imx6q.c
> b/drivers/usb/chipidea/usbmisc_imx6q.c
> new file mode 100644
> index 000..9f69a8c
> --- /dev/null
> +++ b/drivers/usb/chipidea/usbmisc_imx6q.c
> @@ -0,0 +1,161 @@
> +/*
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ci13xxx_imx.h"
> +
> +#define USB_DEV_MAX 4
> +
> +#define BM_OVER_CUR_DIS BIT(7
Discussion about implementation of usb port power off mechanism for port with device
hi alan: I accord to your advice to implement usb port power off mechanism for port with device (add "auto" option for portX/control to allow port to be power off during device being suspended and power on when resuming). http://marc.info/?l=linux-usb&m=133675841421390&w=2 I still don't see what the problem is. They don't have to be synchronized; all you need to do is make sure that the port's state remains set to "off" until the debouncing is finished and you have turned off the connect-change and enable-change features. But the device is still disconnected after powering on the port during resuming. Caused by that port_power had been set to "on" when connect-change event was processed. My patch is at the bottom of the mail. If something wrong, please help me to correct. Thanks. Following is output, I add some debug infos in my code when port's power_state is set to "on" or "off" and device attached to port is disconnected. [ 559.575298] usb 1-2: usb auto-suspend, wakeup 0 [ 559.586280] usb_port_suspend: 2926 set port2 power off [ 559.586295] bus-0329 [4294967270] __acpi_bus_set_power : Device [HSP2] transitioned to D3 [ 559.586302] usb usb1: The power of hub port 2 was set to 0 [ 561.728637] hub 1-0:1.0: hub_suspend [ 561.728647] usb usb1: bus auto-suspend, wakeup 0 [ 898.124290]utils-0286 [4294967270] evaluate_integer : Return value [3072] [ 898.124297] bus-0263 [4294967270] __acpi_bus_set_power : Device is already at D3 [ 898.124300] bus-0263 [4294967270] __acpi_bus_set_power : Device is already at D3 [ 898.124303] bus-0263 [4294967270] __acpi_bus_set_power : Device is already at D0 [ 898.124306] bus-0263 [4294967270] __acpi_bus_set_power : Device is already at D0 [ 898.124309] bus-0263 [4294967270] __acpi_bus_set_power : Device is already at D0 [ 898.124559]utils-0286 [4294967274] evaluate_integer : Return value [3092] [ 901.773438] usb usb1: usb auto-resume [ 901.784546] hub 1-0:1.0: hub_resume [ 901.784560] hub 1-0:1.0: port 1: status 0307 change [ 901.784564] hub 1-0:1.0: port 2: status change [ 901.784608] hub 1-0:1.0: state 7 ports 4 chg 0004 evt [ 901.784618] hub 1-0:1.0: port 2, status , change , 12 Mb/s [ 901.805532] usb 1-1: usb auto-resume [ 901.805580] hub 1-0:1.0: state 7 ports 4 chg evt 0002 [ 901.842482] usb 1-1: finish resume [ 901.843776] bus-0329 [4294967274] __acpi_bus_set_power : Device [HSP2] transitioned to D0 [ 901.843784] usb usb1: The power of hub port 2 was set to 1 [ 901.864999] hub 1-0:1.0: state 7 ports 4 chg evt 0004 [ 901.865015] hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s [ 901.973316] hub 1-0:1.0: debounce: port 2: total 125ms stable 100ms status 0x101 [ 901.973324] usb_port_resume: port2 connect state on 4295567693 [ 901.973331] usb 1-2: finish reset-resume [ 902.024255] hub 1-0:1.0: port 2 not reset yet, waiting 50ms [ 902.126373] usb 1-2: reset high-speed USB device number 3 using xhci_hcd [ 902.143173] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88014032ae80 [ 902.143188] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 88014032aec0 [ 902.143195] usb 1-2: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes [ 902.143198] usb 1-2: ep 0x82 - rounding interval to 32768 microframes, ep desc says 0 microframes [ 902.143324] usb 1-2: Successful Endpoint Configure command [ 902.143716] hub_port_connect_change: port2 attached device disconnect 4295567863 [ 902.143720] usb 1-2: USB disconnect, device number 3 [ 902.143722] usb 1-2: unregistering device [ 902.143724] usb 1-2: unregistering interface 1-2:1.0 [ 902.144514] usb 1-2: usb_disable_device nuking all URBs [ 902.144576] usb 1-2: Successful Endpoint Configure command [ 902.247875] hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x503 [ 902.29] hub 1-0:1.0: port 2 not reset yet, waiting 50ms [ 902.400758] usb 1-2: new high-speed USB device number 4 using xhci_hcd [ 902.419019] usb 1-2: default language 0x0409 [ 902.425862] usb 1-2: udev 4, busnum 1, minor = 3 [ 902.425867] usb 1-2: New USB device found, idVendor=0bda, idProduct=0158 [ 902.425869] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 902.425871] usb 1-2: Product: USB2.0-CRW [ 902.425873] usb 1-2: Manufacturer: Generic [ 902.425874] usb 1-2: SerialNumber: 2006041309210 [ 902.426089] usb 1-2: usb_probe_device [ 902.426093] usb 1-2: configuration #1 chosen from 1 choice [ 902.426101] usb 1-2: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes [ 902.426104] usb 1-2: ep 0x82 - rounding interval to 32768 microframes, ep desc says 0 microframes [ 902.426176] usb 1-2: Successful Endpoint Configure command [ 902.426689] usb 1-2: adding 1-2:1.0 (config #1, interface 0) [ 902.427409] uas 1-2:1.0: usb_probe_interfac
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi, On 06/22/2012 05:43 PM, Munegowda, Keshava wrote: > On Fri, Jun 22, 2012 at 7:41 PM, Kevin Hilman wrote: >> "Munegowda, Keshava" writes: >> >> [...] >> >> >> You are not reading what I write. >> >> To repeat: your patch fixes the oops during boot, and the suspend hang >> and now I see CORE hit retention in *suspend*. > > thanks ! > >> >> However, CORE does still not hit retention during *idle*. > > here is the problem. > > usb host retention in idle is not supported till now. > in current code, usb host cuts clock only in driver suspend not in bus > suspend ( auto suspend). > usb host driver need to use the io daisy chain framework through io wakeup. > I will post the patches once ehci remote wakeup features stabilized in > omap3, omap4 and omap5 too. > We are talking about CORE retention support during idle. How is IO daisy chaining related to that? Doesn't IO daisy chain only apply when device hits OFF? 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: [RFC] firmware load: defer request_firmware during early boot and resume
On Sun, Jul 22, 2012 at 12:46:13PM -0700, Linus Torvalds wrote: > On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov wrote: > > > > Question: is there any other reason > > > > [besides maybe embedded people who care about each single Kb of memory > >on the system] > > > > why we don't make this cache/uncache firmware thing *implicit*? That is, > > load it once at driver open time and keep it in memory during the whole > > driver's lifetime. And this all taken care of by the driver core, btw. > > So some firmware is a *lot* more than "a few kB". We're talking > hundreds of kB, sometimes more. Ok. > And to make matters worse, we keep it in memory with vmalloc(), which > is a limited resource on 32-bit systems. So it can actually be worse > than just the memory use itself. Ok, a follow-up: why do we use vmalloc space for firmware, actually? Because it can be a lot more than a few KB as you say above and a normal kmalloc allocation could fail in such a case? Becase I recently converted the AMD microcode driver to use a normal get_zeroed_page page and got rid of all the vmalloc allocations it did and it is still working :). What I'm saying is, we probably could take care of the vmalloc issue by allocating firmware memory early enough so that we can always succeed. Oh, I see one problem here - the driver could be loaded very late in the system lifetime and we could be having fragmented physical memory so that kmalloc does actually fail. In such cases, we can fallback to vmalloc I guess. Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- 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
