Re: 4.14 dwc3 gadget mode panic
On Sat, 25 Nov 2017 16:39:52 +, Vincent Pelletier
wrote:
> To my surprise, the error symptom do not seem to change:
Having read some more on kernel debugging and especially critical
sections, I realise that while the general issue is still there, the
symptom did change consistently with modified code: what was
> [ 382.207124] 4 locks held by screen/1808:
> [ 382.211266] #0: (rcu_callback){}, at: []
> rcu_process_callbacks+0x260/0x440
> [ 382.219949] #1: (rcu_read_lock_sched){}, at: []
> percpu_ref_switch_to_atomic_rcu+0xb0/0x130
> [ 382.230034] #2: (&(&ctx->ctx_lock)->rlock){}, at: []
> free_ioctx_users+0x23/0xd0
> [ 382.230096] #3: (&(&ffs->eps_lock)->rlock){}, at: []
> ffs_aio_cancel+0x20/0x60 [usb_f_fs]
became
> [ 382.511767] 3 locks held by swapper/1/0:
> [ 382.515903] #0: (rcu_callback){}, at: []
> rcu_process_callbacks+0x260/0x440
> [ 382.524572] #1: (rcu_read_lock_sched){}, at: []
> percpu_ref_switch_to_atomic_rcu+0xb0/0x130
> [ 382.534650] #2: (&(&ctx->ctx_lock)->rlock){}, at: []
> free_ioctx_users+0x23/0xd0
Then, I looked a bit at these. free_ioctx_users is called via
percpu_ref_init, which specifies that:
/**
* percpu_ref_init - initialize a percpu refcount
[...]
* Note that @release must not sleep - it may potentially be called from RCU
* callback context by percpu_ref_kill().
*/
On the other end, if I understand dwc3_gadget_ep_dequeue correctly it
has to wait for hardware to confirm it will not touch the transfer, so
some sleeping seems required.
So far I lack proper knowledge to tell how to get both sides to agree.
Taking a peed at dwc2, I see it does not call wait_event_lock_irq but
instead does a busy loop checking chip registers and waiting 1µs
between loop (I guess this does not count as "sleeping", as I think no
context switch can happen).
In dwc3, DWC3_EP_END_TRANSFER_PENDING flag gets cleared during
interrupt handling (bottom-half handler) and not by polling a
register, so it does not seem possible (...or at least trivial) to
transpose the dwc2 way, so I'm not sure where to go from here.
Regards,
--
Vincent Pelletier
--
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 0/2] usb: typec: alternate mode bus
Hi Heiko, On 28-09-17 13:35, Heikki Krogerus wrote: Hi guys, The bus allows SVID specific communication with the partners to be handled in separate drivers for each alternate mode. Alternate mode handling happens with two separate logical devices: 1. Partner alternate mode devices which represent the alternate modes on the partner. The driver for them will handle the alternate mode specific communication with the partner using VDMs. 2. Port alternate mode devices which represent connections from the USB Type-C port to devices on the platform. The drivers will be bind to the partner alternate modes. The alternate mode drivers will need to deliver the result of the negotiated pin configurations to the rest of the platform (towards the port alternate mode devices). This series includes API for that, however, not the final implementation yet. The connections to the other devices on the platform the ports have can be described by using the remote endpoint concept [1][2] on ACPI and DT platforms, but I have no solution for the "platform data" case where we have neither DT nor ACPI to describe the connections for us. Sorry about the slow reply, I've been a bit swamped with other stuff, but now I would like to get back to this. I've been trying to wrap my head around what you're proposing here and I see how this can help with implementing display-port alternate mode support, but I don't see how it is going to help with regular superspeed USB support / the mux problem. The problems I see / questions I have are: 1) This seems to be driven by having a bus using svid-s as match functions, but the standard USB function does not have any svid, or at least currently does not show as such under e.g. /sys/class/typec/port0/port0-partner 2) The alt-mode drivers you are suggesting seem to be about 2 things: a) Alt-mode specific PD communication b) Telling other components about pin-configs, e.g. telling the i915 driver how much display port lanes are configured What this seems to miss a mechanism to control the mux between the "superspeed" data-pairs on the port and the dp-port pins on the SoC / the superspeed USB pins on the SoC. Even leaving display-port out of the picture for now we still need to control the port -> SoC superspeed pins routing which need to be one of: tristated (default) / normal / upside-down routing. ### end Type-c discussion ### ### Related USB device/host mode switch discussion ### Another problem for USB is even once the right pins on the port are routed to the right pins on the SoC then the SoC may have an internal mux to route all the USB pins (both USB-2 and superspeed) to either the host or device USB controller. My previous patches for this tried to use the mux framework for this, but that was nacked because of a misunderstanding how the current mux framemork works. The current mux framework is based on the notion of there being a shared bus between e.g. the SoC and various devices, where the devices are not directly addressable from the bus, but there is a mux in between which connects the SoC to the device it wants to talk to. So the SoC can reach all connected devices, but only one add at a time. To make this clear a driver talking to one of the devices needs to switch the mux to a specific device and then release the mux when it is done. If another driver tries to switch the mux before it is released its request will block until the mux gets released. With USB OTG / Type-C things are different, there is only one device connected, and depending on which type of device is detected as being connected we need to connect the OTG / Type-C port pins to the corresponding controller inside the SoC. There is no "time-shared" access to multiple devices at the same time. Thus the current mux subsys is a poor match for the needs for USB OTG / Type-C. One option I've been considering is to introduce a new usb_mux subsys when I get around to this (hopefully sometime the coming month) which will be modelled after the mux subsys, but without the "time-sharing" concepts and thus without the need to release a mux setting before the mux can be switched to route the data else where. My primary target here is using this on devices with a micro-usb connector, traditionally on ARM systems the mux in these devices has been hidden inside the phy-driver. But on x86 systems: a) The phy is setup from firmware and we don't have a phy driver; and b) Often the mux is not part of the phy at all, instead we have a separate mux (sometimes in separate IC outside the SoC) driven by gpios or i2c. I think we could extend this usb_mux subsys easily to also handle the mux parts of type-c (specifically controlling mux ICs such as the PI3USB30532 USB switch). Regards, Hans [1] Documentation/devicetree/bindings/graph.txt [2] Documentation/acpi/dsd/graph.txt Heikki Krogerus (2): usb: typec: Simple bus for alternate modes usb: typec: dummy alternate mode driver drivers/usb/typec/Kconfig
[PATCH] USB: serial: Correct return value on read
It's meaningless to return buf[0] on read. Because the caller of this interface checks the return value negative or not. Instead, we should return the result variable. Signed-off-by: Gimcuan Hui --- drivers/usb/serial/ark3116.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c index 3c544782f60b..bfdbc7164e7b 100644 --- a/drivers/usb/serial/ark3116.c +++ b/drivers/usb/serial/ark3116.c @@ -101,11 +101,9 @@ static int ark3116_read_reg(struct usb_serial *serial, reg, result); if (result >= 0) result = -EIO; - - return result; } - return buf[0]; + return result; } static inline int calc_divisor(int bps) -- 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: [RFC v3] Add support for Sony PS2 OHCI
Hi Alan Stern,
> > Be aware that your driver should utilize ohci_init_driver(), like
> > several of the other platform-specific OHCI drivers do. Unless there's
> > some very good reason, new drivers should never use the old interface.
>
> Agreed, please find updated patch with the new interface. (I suppose the
> changes to drivers/usb/host/ohci-hcd.c eventually will have to be clarified
> and moved elsewhere too.)
The original author Jürgen Urban has made several improvements to v3 of the
driver, shown below. To make progress we had to remove this WARN_ON line:
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -527,7 +527,6 @@ static inline void dma_free_attrs(struct device *dev,
size_t size,
const struct dma_map_ops *ops = get_dma_ops(dev);
BUG_ON(!ops);
- WARN_ON(irqs_disabled());
if (dma_release_from_dev_coherent(dev, get_order(size), cpu_addr))
return;
We also tried a change along the lines of
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -444,8 +444,13 @@ static int ohci_init (struct ohci_hcd *ohci)
int ret;
struct usb_hcd *hcd = ohci_to_hcd(ohci);
- /* Accept arbitrarily long scatter-gather lists */
- hcd->self.sg_tablesize = ~0;
+ if (hcd->self.uses_dma) {
+ /* Accept arbitrarily long scatter-gather lists */
+ hcd->self.sg_tablesize = ~0;
+ } else {
+ /* DMA not supported. */
+ hcd->self.sg_tablesize = 0;
+ }
if (distrust_firmware)
ohci->flags |= OHCI_QUIRK_HUB_POWER;
to address the issue of scatter-gather in combination with HCD_LOCAL_MEM and
dma_declare_coherent_memory().
The PS2 kernel is currently somewhat unstable, but it is at the moment unclear
whether this is due to its OHCI driver.
What are your thoughts on these changes and the driver patch below?
Fredrik
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -571,6 +571,13 @@ config USB_OHCI_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
+config USB_OHCI_HCD_PS2
+ tristate "OHCI support for the Sony PlayStation 2"
+ depends on SONY_PS2
+ default y
+ help
+Enable support for the Sony PlayStation 2 OHCI controller.
+
config USB_CNS3XXX_OHCI
bool "Cavium CNS3XXX OHCI Module (DEPRECATED)"
depends on ARCH_CNS3XXX
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_USB_OHCI_HCD_S3C2410)+= ohci-s3c2410.o
obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
obj-$(CONFIG_USB_OHCI_HCD_PXA27X) += ohci-pxa27x.o
obj-$(CONFIG_USB_OHCI_HCD_DAVINCI) += ohci-da8xx.o
+obj-$(CONFIG_USB_OHCI_HCD_PS2) += ohci-ps2.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-ps2.c b/drivers/usb/host/ohci-ps2.c
new file mode 100755
--- /dev/null
+++ b/drivers/usb/host/ohci-ps2.c
@@ -0,0 +1,338 @@
+/*
+ * USB OHCI HCD (Host Controller Driver) for the PlayStation 2.
+ *
+ * Copyright (C) 2017 Jürgen Urban
+ * Copyright (C) 2017 Fredrik Noring
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "ohci.h"
+
+/* Enable USB OHCI hardware. */
+#define DPCR2_ENA_USB 0x0800
+
+/* Enable PS2DEV (required for PATA and USB). */
+#define DPCR2_ENA_PS2DEV 0x0080
+
+#define DRIVER_DESC "OHCI PS2 driver"
+#define DRV_NAME "ohci-ps2"
+
+/* Size allocated from IOP heap (maximum size of DMA memory). */
+#define DMA_BUFFER_SIZE (256 * 1024)
+
+/* Get driver private data. */
+#define hcd_to_priv(hcd) (struct ps2_hcd *)(hcd_to_ohci(hcd)->priv)
+
+struct ps2_hcd {
+ void __iomem *dpcr2;/* FIXME: Is a lock required for DPCR2? */
+ dma_addr_t iop_dma_addr;
+ bool wakeup;/* Saved wake-up state for resume. */
+};
+
+static struct hc_driver __read_mostly ohci_ps2_hc_driver;
+
+static void ohci_ps2_enable(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+
+ BUG_ON(!ohci->regs);
+
+ /* This is needed to get USB working on PS2. */
+ ohci_writel(ohci, 1, &ohci->regs->roothub.portstatus[11]);
+}
+
+static void ohci_ps2_disable(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+
+ WARN_ON(!ohci->regs);
+
+ if (ohci->regs)
+ ohci_writel(ohci, 0, &ohci->regs->roothub.portstatus[11]);
+}
+
+static void ohci_ps2_start_hc(struct usb_hcd *hcd)
+{
+ struct ps2_hcd *ps2priv = hcd_to_priv(hcd);
+
+ /*
+* Enab
very slow USB security token access after switch from 2.6.13 to 4.4.52
Hello dear linux USB users and developers,
I've got a bit desperate question, but maybe somebody will have
some idea on what to try..
we're migrating lots (thousands) of users from very old opensuse running
2.6.13 kernel to new centos based system running 4.4.52 kernel.
There are security tokens in use on desktops - Ikey 4000. They work,
but on new system initialisation of token and reading certificates is taking
very long, slowing firefox (and other pkcs11 users) start by ~20seconds. Since
users are running those token using apps very often, this is causing lots of
hassle..
The problem is, that token support is proprietary, I don't have any sources,
just
those arcane opensc + openct binaries built for opensuse I'm forced to on new
system
(therefore I'm also using 32bit firefox). Since the switch to new tokens with
better
support is planned on next year, I'd really love to resolve this issue.
I've tried tracing all related binaries, and I think the problem is in
ifdhandler
slow access to device..
sample ifdhandler debug output is here:
Debug: ifdhandler_process: ifdhandler_process(cmd=CT_CMD_TRANSACT, unit=0)
Debug: ifd_protocol_transceive: cmd: 00 b0 04 ec dd
Debug: t1_xcv: sending 00 00 05 00 b0 04 ec dd 80
Debug: ifd_usb_control: usb req type=x41 req=x17 val=x ind=x0005 len=5
Debug: ifd_usb_control: send b0 04 ec dd 80
Debug: ifd_usb_control: usb req type=xc1 req=x01 val=x ind=x len=255
Debug: ifd_usb_control: recv 00 c3 01 26 e4 04 ec dd 80 02 10 00 34 8b 9f 8e
07 f4 22 de bc 60 fb a8 a0 8a a4 0c 11 0f 33 90 00 01 1c ad 80 1b 84 31 2a 40
11 fe 4d 18 23 08 c6 cd 90 b5 44 01 21 24 88 a6 0b 40 94 21 78 78 b0 95 72 19
20 e0 1a a6 07 e3 69 c4 41 4c 00 66 04 a3 01 b2 d0 c1 32 0a 60 05 56 d8 16 d1
b4 04 10 05 80 c4 87 8c 61 12 73 5a fa a8 61 b4 28 25 ba 4c 24 92 c9 28 9a 84
49 0b 00 4a 27 94 45 02 81 11 ed 42 a2 90 c0 aa b0 91 59 04 6a 20 a1 2b 40 c3
27 3c 05 a9 4a 2d 05 00 02 87 91 28 10 17 16 ad 00 41 42 92 20 94 18 20 83 cb
ae 42 0e 58 52 d1 00 29 41 12 3c 40 00 c3 01 26 e4 04 ec dd 80 02 10 00 34 8b
9f 8e 07 f4 22 de bc 60 fb a8 a0 8a a4 0c 11 0f 33 90 00 01 1c ad 80 1b 84 31
2a 40 11 fe 4d 18 23 08 c6 cd 90 b5 44 01 21 24 88 a6 0b 40 94 21 78 78 b0 95
72 19 20 e0 1a
Debug: t1_xcv: received 00 c3 01 26 e4
Debug: t1_transceive: CT sent S-block with wtx=38
Debug: t1_xcv: sending 00 e3 01 26 c4
Debug: ifd_usb_control: usb req type=x41 req=x17 val=xe300 ind=x2601 len=1
Debug: ifd_usb_control: send c4
Debug: ifd_usb_control: usb req type=xc1 req=x01 val=x ind=x len=255
Debug: ifd_usb_control: recv 00 60 20 35 9c b6 98 cd e1 e2 18 08 f0 8b 42 8d
c9 b2 3f f7 09 35 29 dc 95 cf 58 f5 91 c1 2d 86 37 2a dc 1a 80 1b 84 31 2a 40
11 fe 4d 18 23 08 c6 cd 90 b5 44 01 21 24 88 a6 0b 40 94 21 78 78 b0 95 72 19
20 e0 1a a6 07 e3 69 c4 41 4c 00 66 04 a3 01 b2 d0 c1 32 0a 60 05 56 d8 16 d1
b4 04 10 05 80 c4 87 8c 61 12 73 5a fa a8 61 b4 28 25 ba 4c 24 92 c9 28 9a 84
49 0b 00 4a 27 94 45 02 81 11 ed 42 a2 90 c0 aa b0 91 59 04 6a 20 a1 2b 40 c3
27 3c 05 a9 4a 2d 05 00 02 87 91 28 10 17 16 ad 00 41 42 92 20 94 18 20 83 cb
ae 42 0e 58 52 d1 00 29 41 12 3c 40 00 60 20 35 9c b6 98 cd e1 e2 18 08 f0 8b
42 8d c9 b2 3f f7 09 35 29 dc 95 cf 58 f5 91 c1 2d 86 37 2a dc 1a 80 1b 84 31
2a 40 11 fe 4d 18 23 08 c6 cd 90 b5 44 01 21 24 88 a6 0b 40 94 21 78 78 b0 95
72 19 20 e0 1a
(repeats many times).
strace of the same process:
18:27:24 poll([{fd=3, events=POLLHUP}, {fd=4, events=POLLIN}, {fd=6,
events=POLLOUT}], 3, 1000) = 1 ([{fd=6, revents=POLLOUT}])
18:27:24 time(NULL) = 1511717244
18:27:24 rt_sigaction(SIGPIPE, {SIG_IGN, [], 0}, {SIG_IGN, [], 0}, 8) = 0
18:27:24 write(6,
"\v\0\0\0\0\0\0\0\0\0)\0E\0&P1\t\355\17\17\17\17\17\17\0\0\1\0\0\0\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\0\0\1\0\220\0",
53) = 53
18:27:24 rt_sigaction(SIGPIPE, {SIG_IGN, [], 0}, {SIG_IGN, [], 0}, 8) = 0
18:27:24 time(NULL) = 1511717244
18:27:24 poll([{fd=3, events=POLLHUP}, {fd=4, events=POLLIN}, {fd=6,
events=POLLOUT}], 3, 1000) = 1 ([{fd=6, revents=POLLOUT}])
18:27:24 time(NULL) = 1511717244
18:27:24 rt_sigaction(SIGPIPE, {SIG_IGN, [], 0}, {SIG_IGN, [], 0}, 8) = 0
18:27:24 rt_sigaction(SIGPIPE, {SIG_IGN, [], 0}, {SIG_IGN, [], 0}, 8) = 0
18:27:24 time(NULL) = 1511717244
18:27:24 poll([{fd=3, events=POLLHUP}, {fd=4, events=POLLIN}, {fd=6,
events=POLLIN}], 3, 1000) = 1 ([{fd=6, revents=POLLIN}])
18:27:24 time(NULL) = 1511717244
18:27:24 read(6, "\f\0\0\0\0\0\0\0\0\0\n\0!\0\304\0\5\0\260\0\0\374", 3857) = 22
18:27:24 time(NULL) = 1511717244
18:27:24 ioctl(3, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xffdd9304) = 5
18:27:24 ioctl(3, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xffdd9304) =
255
18:27:24 ioctl(3, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xffdd9304) = 1
18:27:24 ioctl(3, SNDRV_CTL_IOCTL_PVERSION or USBDEVFS_CONTROL, 0xffdd9304) =
255
New CP210x device
Hello,
I have a USB device which I just obtained as part of my medical
utilities. It is a OneTouch Verio IQ glucometer. After plugging it in
to my Linux machine running 4.4.95 I obtained the device vendor and Id
strings. I have added the strings to cp210x.c and built a new kernel,
4.4.102. The device is now recognized as a ttyUSB. Here is my dmesg
output:
[50675.033021] usb 5-1: new full-speed USB device number 7 using uhci_hcd
[50675.188015] usb 5-1: New USB device found, idVendor=10c4, idProduct=85a7
[50675.188022] usb 5-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[50675.188025] usb 5-1: Product: CP2103 USB to UART Bridge Controller
[50675.188028] usb 5-1: Manufacturer: Silicon Labs
[50675.188031] usb 5-1: SerialNumber: TGKHQ0M9
[50675.194103] cp210x 5-1:1.0: cp210x converter detected
[50675.194318] usb 5-1: cp210x converter now attached to ttyUSB1
I've included a patch for the cp210x.c file.
Regards,
Frederick
diff -upr a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
--- a/drivers/usb/serial/cp210x.c 2017-11-25 11:33:48.369655206 -0600
+++ b/drivers/usb/serial/cp210x.c 2017-11-26 09:27:15.225565082 -0600
@@ -120,6 +120,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x8470) }, /* Juniper Networks BX Series System Console */
{ USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */
{ USB_DEVICE(0x10C4, 0x84B6) }, /* Starizona Hyperion */
+ { USB_DEVICE(0x10C4, 0x85A7) }, /* OneTouch Verio IQ Glucometer */
{ USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */
{ USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */
{ USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */
Re: usbip port number limits
Hi Juan, On Fri, Nov 24, 2017 at 12:42:22PM +0100, Juan Zea wrote: >The patch doesn't apply cleanly with the patch command, but given it is > that simple I've changed it myself (I'm telling you just in case we're > missing something). > >The fingerprint reader, usb stick and wacom tablet work :) Good to hear that. > I've also checked the same patch can be applied to kernel master and it > works. So... is that the solution? I'll post a patch later, but before that, Hi, Shuah, does it work for you, on your test notebook? Thanks, Yuyang -- 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
