[PATCH] usb: gadget: allow serial gadget console on other configs
From: Thadeu Lima de Souza Cascardo <casca...@cascardo.eti.br> USB gadget serial console works on functions other than the legacy configurations. Let the user enable it when using any function that uses the serial utilities. Signed-off-by: Thadeu Lima de Souza Cascardo <casca...@cascardo.eti.br> --- drivers/usb/gadget/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 35cc641d9f31..31cce7805eb2 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -130,7 +130,7 @@ config USB_GADGET_STORAGE_NUM_BUFFERS config U_SERIAL_CONSOLE bool "Serial gadget console support" - depends on USB_G_SERIAL + depends on USB_U_SERIAL help It supports the serial gadget can be used as a console. -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Missing USB XHCI and EHCI reset for kexec
On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote: Zitat von Benjamin Herrenschmidt b...@au1.ibm.com: I don't know about EHCI specifically but this is a known issue with XHCI, I observe similar issues on other powerpc platforms (servers) and this isn't architecture specific (looks more like actualy xhc implementation specific). Thadeu Cascardo (on CC) has been the one investigating that on our side, he might have more to add including patches. I have now a kernel 3.14 dmesg log of the problem. After a kexec the kexeced 3.14 kernel shows: [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered, assigned bus number 1 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000 microseconds. [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110 What is your controller vendor and device IDs? Is that a TI chip? Yes it is a TI chip, vendor ID 104c and product ID 8241. Can you check if the patch I sent a month ago fixes it? [1] There's the whole story there. In fact, you will also need something like the patch below. Can you apply only the first one, verify, and, then, the other one as well, and report what worked for you? [1] http://marc.info/?l=linux-usbm=139483181809062w=2 I tried the attach patch and it did not help. This is what i expected because this is a fix in the shutdown path, which will never called when doing a forced kexec. Hi, Stefani. Did you try with both patches applied? How do you evoke the forced kexec? Is that a kexec on panic? Does it really need to be forced? With no clean shutdown, platform and drivers would need to issue resets, like you mentioned below, to get the system into a clean state. I have a running a 3.10.23 kernel. This kernel do a kexec for a kernel 3.14. Since the kernel 3.10.23 did not performe a clean shutdown, the state of the XHCI Controller is undefined. So when And the clean shutdown requires both of my patches, for TI chips, as far as I know. It looks like the problem is issuing a halt when there are pending URBs. kernel 3.14 will probe XHCI it will find a XHCI controller which was not performed a reset. The problem is not that a reset hasn't been issued. A PCI function reset should fix most of the problems with a bad device state, when the reset works. However, the problem is that it was not cleanly shut down. URBs should have been canceled and removed from the controller queue, and it should have halted after that. So i think it is necessary to reset the XHCI controller and all devices on this bus. This is what i do with a echo 1 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec. One way to look at that is making the PCI code issue resets to all buses before doing any other access. That will make booting more slow, and there are a lot of other corner cases where this might not be enough. It's probably more sane to try to get the 3.10.23 kernel to do a clean shutdown, if possible. Regards. Cascardo. - Stefani -- 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: Missing USB XHCI and EHCI reset for kexec
On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote: Zitat von Benjamin Herrenschmidt b...@au1.ibm.com: I don't know about EHCI specifically but this is a known issue with XHCI, I observe similar issues on other powerpc platforms (servers) and this isn't architecture specific (looks more like actualy xhc implementation specific). Thadeu Cascardo (on CC) has been the one investigating that on our side, he might have more to add including patches. I have now a kernel 3.14 dmesg log of the problem. After a kexec the kexeced 3.14 kernel shows: [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered, assigned bus number 1 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000 microseconds. [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110 What is your controller vendor and device IDs? Is that a TI chip? Yes it is a TI chip, vendor ID 104c and product ID 8241. Can you check if the patch I sent a month ago fixes it? [1] There's the whole story there. In fact, you will also need something like the patch below. Can you apply only the first one, verify, and, then, the other one as well, and report what worked for you? [1] http://marc.info/?l=linux-usbm=139483181809062w=2 I tried the attach patch and it did not help. This is what i expected because this is a fix in the shutdown path, which will never called when doing a forced kexec. Hi, Stefani. Did you try with both patches applied? How do you evoke the forced kexec? Is that a kexec on panic? Does it really need to be forced? With no clean shutdown, platform and drivers would need to issue resets, like you mentioned below, to get the system into a clean state. Yes, i applied both patches. But without success. IMHO i think it is necessary to bring the device i a clean state when the driver use the HW. I have a running a 3.10.23 kernel. This kernel do a kexec for a kernel 3.14. Since the kernel 3.10.23 did not performe a clean shutdown, the state of the XHCI Controller is undefined. So when And the clean shutdown requires both of my patches, for TI chips, as far as I know. It looks like the problem is issuing a halt when there are pending URBs. kernel 3.14 will probe XHCI it will find a XHCI controller which was not performed a reset. The problem is not that a reset hasn't been issued. A PCI function reset should fix most of the problems with a bad device state, when the reset works. However, the problem is that it was not cleanly shut down. URBs should have been canceled and removed from the controller queue, and it should have halted after that. Again, i think it is the job of the driver to bring the chip in a clean state before using them. A driver should never expect a reset state of a chip. So i think it is necessary to reset the XHCI controller and all devices on this bus. This is what i do with a echo 1 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec. One way to look at that is making the PCI code issue resets to all buses before doing any other access. That will make booting more slow, and there are a lot of other corner cases where this might not be enough. It's probably more sane to try to get the 3.10.23 kernel to do a clean shutdown, if possible. With this driver design the kexec functionality is usesless on PowerPC. X86 looks a little bit better. - Stefani What is the vendor and device ID you are using on your X86 system? This is not a matter of what architecture you are using, it's the XHCI controller which does not behave as well as the one you are using on X86, which is likely an Intel one. Cascardo. -- 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: Missing USB XHCI and EHCI reset for kexec
On Tue, Apr 15, 2014 at 08:42:58PM +0200, Stefani Seibold wrote: Am Dienstag, den 15.04.2014, 15:33 -0300 schrieb Thadeu Lima de Souza Cascardo: On Tue, Apr 15, 2014 at 05:00:28PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Tue, Apr 15, 2014 at 12:04:17PM +0200, stef...@seibold.net wrote: Zitat von Thadeu Lima de Souza Cascardo casca...@linux.vnet.ibm.com: On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote: Zitat von Benjamin Herrenschmidt b...@au1.ibm.com: I don't know about EHCI specifically but this is a known issue with XHCI, I observe similar issues on other powerpc platforms (servers) and this isn't architecture specific (looks more like actualy xhc implementation specific). Thadeu Cascardo (on CC) has been the one investigating that on our side, he might have more to add including patches. I have now a kernel 3.14 dmesg log of the problem. After a kexec the kexeced 3.14 kernel shows: [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered, assigned bus number 1 [1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000 microseconds. [1.219621] xhci_hcd 0001:03:00.0: can't setup: -110 [1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered [1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110 [1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110 What is your controller vendor and device IDs? Is that a TI chip? Yes it is a TI chip, vendor ID 104c and product ID 8241. Can you check if the patch I sent a month ago fixes it? [1] There's the whole story there. In fact, you will also need something like the patch below. Can you apply only the first one, verify, and, then, the other one as well, and report what worked for you? [1] http://marc.info/?l=linux-usbm=139483181809062w=2 I tried the attach patch and it did not help. This is what i expected because this is a fix in the shutdown path, which will never called when doing a forced kexec. Hi, Stefani. Did you try with both patches applied? How do you evoke the forced kexec? Is that a kexec on panic? Does it really need to be forced? With no clean shutdown, platform and drivers would need to issue resets, like you mentioned below, to get the system into a clean state. Yes, i applied both patches. But without success. IMHO i think it is necessary to bring the device i a clean state when the driver use the HW. I have a running a 3.10.23 kernel. This kernel do a kexec for a kernel 3.14. Since the kernel 3.10.23 did not performe a clean shutdown, the state of the XHCI Controller is undefined. So when And the clean shutdown requires both of my patches, for TI chips, as far as I know. It looks like the problem is issuing a halt when there are pending URBs. kernel 3.14 will probe XHCI it will find a XHCI controller which was not performed a reset. The problem is not that a reset hasn't been issued. A PCI function reset should fix most of the problems with a bad device state, when the reset works. However, the problem is that it was not cleanly shut down. URBs should have been canceled and removed from the controller queue, and it should have halted after that. Again, i think it is the job of the driver to bring the chip in a clean state before using them. A driver should never expect a reset state of a chip. So i think it is necessary to reset the XHCI controller and all devices on this bus. This is what i do with a echo 1 /sys/bus/pci/drivers/xhci_hcd/0001:03:00.0/reset before the kexec. One way to look at that is making the PCI code issue resets to all buses before doing any other access. That will make booting more slow, and there are a lot of other corner cases where this might not be enough. It's probably more sane to try to get the 3.10.23 kernel to do a clean shutdown, if possible. With this driver design the kexec functionality is usesless on PowerPC. X86 looks a little bit better. - Stefani What is the vendor and device ID you are using on your X86 system? This is not a matter of what architecture you are using, it's the XHCI controller which does not behave as well as the one you are using on X86, which is likely an Intel one. It is an Intel 8086:8c31. But this was only a side note. We need a generic solution not a vendor specific one. Otherwise kexec is useless on other architectures. - Stefani It's probably useless on X86 with a TI XHCI board. I just don't have such an environment to test. Can you arrange to test that? If that shows me wrong, we certainly need to investigate
Re: Missing USB XHCI and EHCI reset for kexec
On Mon, Apr 14, 2014 at 05:44:58PM +0200, stef...@seibold.net wrote:
Zitat von Benjamin Herrenschmidt b...@au1.ibm.com:
On Sun, 2014-04-13 at 21:22 +0200, Stefani Seibold wrote:
When executing a kexec kernel on a PowerPC board the new started kernel
will not find already enumerated USB devices due a missing reset on the
USB bus.
As a work around a
echo 1 /sys/bus/pci/drivers/[ex]hci-pci/BUS-ADDRESS-OF-THE-HCD/reset
will solve this. But this is far from beauty.
My latest kernel without this issue was for EHCI kernel 2.6.39 and for
XHCI kernel 3.4, but i have no idea when exactly this behavior was
introduced.
For X86 all is fine.
I don't know about EHCI specifically but this is a known issue with
XHCI, I observe similar issues on other powerpc platforms (servers)
and this isn't architecture specific (looks more like actualy xhc
implementation specific).
Thadeu Cascardo (on CC) has been the one investigating that on our side,
he might have more to add including patches.
I have now a kernel 3.14 dmesg log of the problem. After a kexec the
kexeced 3.14 kernel shows:
[1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
[1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
assigned bus number 1
[1.212561] xhci_hcd 0001:03:00.0: Host not halted after 16000
microseconds.
[1.219621] xhci_hcd 0001:03:00.0: can't setup: -110
[1.224597] xhci_hcd 0001:03:00.0: USB bus 1 deregistered
[1.230021] xhci_hcd 0001:03:00.0: init 0001:03:00.0 fail, -110
[1.235955] xhci_hcd: probe of 0001:03:00.0 failed with error -110
Any idea?
- Stefani
What is your controller vendor and device IDs? Is that a TI chip?
Can you check if the patch I sent a month ago fixes it? [1] There's the
whole story there. In fact, you will also need something like the patch
below. Can you apply only the first one, verify, and, then, the other
one as well, and report what worked for you?
[1] http://marc.info/?l=linux-usbm=139483181809062w=2
Thanks.
Cascardo.
---
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 47390e3..232574f 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -392,7 +392,7 @@ static struct pci_driver xhci_pci_driver = {
.remove = xhci_pci_remove,
/* suspend and resume implemented later */
- .shutdown = usb_hcd_pci_shutdown,
+ .shutdown = xhci_pci_remove,
#ifdef CONFIG_PM
.driver = {
.pm = usb_hcd_pci_pm_ops
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: do not halt the secondary HCD
We can't halt the secondary HCD, because it's also the primary HCD, which will cause problems if we have devices attached to the primary HCD, like a keyboard. --- Not yet signed-off because I am waiting for some kexec testing to be done on another environment, and I would like to bring this into a discussion to maybe come up with a better solution, or confirm this is OK. And probably most of this message should go into the commit log anyway. We have a USB 3.0 card using a TI chip and it doesn't behave very well when we halt it while it still has some pending URBs. We have to disconnect both the USB 3.0 and USB 2.0 devices from the host before we halt. XHCI PCI always create a primary and secondary HCDs, in the form of shared_hcd. The USB 2.0 roothub is created first and removed last, and itÅ the primary HCD. The USB 3.0 roothub is the shared_hcd. The removal calls usb_remove_hcd for the shared_hcd and hsb_hcd_pci_remove for the primary HCD. Ultimately, usb_hcd_pci_remove calls usb_remove_hcd. usb_remove_hcd disconnects the connected devices and calls XHCI stop. xhci_stop will call xhci_only_stop_hcd for the secondary (ie, shared_hcd, which is the USB 3.0 roothub), which calls xhci_halt, and for the USB 2.0 roothub, it will call xhci_halt and do the rest of the cleanup. What seems to happen for the TI chip is that while the HID device is still connected (ie, we still have pending URBs on the queue), halting is not a great idea. And as described above, what is done right now is: 1) disconnect USB 3.0 devices 2) halt 3) disconnect USB 2.0 devices 4) halt and cleanup What I do is avoid halting before we disconnect the USB 2.0 devices. We know that xhci_only_stop_hcd is only called for the secondary for which there is a primary with the same xhci. Much of that information is on the xhci driver itself, so we are not working around the upper layer more than the driver already is. One option we have to be too much invasive here with other chipsets is skip the halt only for the TI host card, by using a new quirk. Regards. Cascardo. --- drivers/usb/host/xhci.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 924a6cc..3fdf8a9 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -651,7 +651,12 @@ static void xhci_only_stop_hcd(struct usb_hcd *hcd) struct xhci_hcd *xhci = hcd_to_xhci(hcd); spin_lock_irq(xhci-lock); - xhci_halt(xhci); + /* +* We can't halt the secondary HCD, because it's also the +* primary HCD, which will cause problems if we have devices +* attached to the primary HCD, like a keyboard. +*/ + /*xhci_halt(xhci);*/ /* The shared_hcd is going to be deallocated shortly (the USB core only * calls this function when allocation fails in usb_add_hcd(), or -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xhci: do not halt the secondary HCD
On Sat, Mar 15, 2014 at 08:31:29AM +1100, Benjamin Herrenschmidt wrote: On Fri, 2014-03-14 at 18:16 -0300, Thadeu Lima de Souza Cascardo wrote: What seems to happen for the TI chip is that while the HID device is still connected (ie, we still have pending URBs on the queue), halting is not a great idea. And as described above, what is done right now is: Can you tell us more about what not a great idea means ? :-) IE, we have experienced actual errors, hangs and/or kexec failures right ? You should describe them so people like Sarah can understand better what's going on and why it's a problem. Right, I forgot about that. And it should probably be in the commit log. As far as I know, we don't get system hangs. What we get are probe failures for the PCI adapter. Since the halt will be executed during remove/shutdown, that can happen for kexec, rmmod or simply unbind. During remove/shutdown, the halt fails as follows: [ 825.368410] xhci_hcd 0003:03:00.0: remove, state 4 [ 825.368606] xHCI xhci_drop_endpoint called for root hub [ 825.368609] xHCI xhci_check_bandwidth called for root hub [ 825.402070] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 825.402098] xhci_hcd 0003:03:00.0: USB bus 2 deregistered [ 825.402486] xhci_hcd 0003:03:00.0: remove, state 1 [ 830.407500] xhci_hcd 0003:03:00.0: xHCI host not responding to stop endpoint command. [ 830.407505] xhci_hcd 0003:03:00.0: Assuming host is dying, halting host. [ 830.440823] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 830.440830] xhci_hcd 0003:03:00.0: Non-responsive xHCI host is not halting. [ 830.440833] xhci_hcd 0003:03:00.0: Completing active URBs anyway. [ 830.440851] xhci_hcd 0003:03:00.0: HC died; cleaning up [ 830.768535] xHCI xhci_drop_endpoint called for root hub [ 830.768539] xHCI xhci_check_bandwidth called for root hub [ 830.801749] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 830.801753] xhci_hcd 0003:03:00.0: Host controller not halted, aborting reset. [ 830.801960] xhci_hcd 0003:03:00.0: USB bus 1 deregistered After that, probe will either get us an EEH, or the following: [ 877.080018] xhci_hcd 0003:03:00.0: xHCI Host Controller [ 877.080463] xhci_hcd 0003:03:00.0: new USB bus registered, assigned bus number 1 [ 877.112931] xhci_hcd 0003:03:00.0: Host not halted after 16000 microseconds. [ 877.112935] xhci_hcd 0003:03:00.0: can't setup [ 877.112941] xhci_hcd 0003:03:00.0: USB bus 1 deregistered [ 877.113203] xhci_hcd 0003:03:00.0: init 0003:03:00.0 fail, -110 [ 877.113221] xhci_hcd: probe of 0003:03:00.0 failed with error -110 Regards. Cascardo. 1) disconnect USB 3.0 devices 2) halt 3) disconnect USB 2.0 devices 4) halt and cleanup What I do is avoid halting before we disconnect the USB 2.0 devices. We know that xhci_only_stop_hcd is only called for the secondary for which there is a primary with the same xhci. Much of that information is on the xhci driver itself, so we are not working around the upper layer more than the driver already is. One option we have to be too much invasive here with other chipsets is skip the halt only for the TI host card, by using a new quirk. Cheers, Ben. -- 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
