[PATCH] usbhid: add quirk for another PIXART OEM mouse used by HP
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 113.027731] usb 2-2: Product: HP USB Optical Mouse
[ 113.069977] usb 2-2: Manufacturer: PixArt
[ 113.113500] input: PixArt HP USB Optical Mouse as
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
[ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse
[PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
[ 173.262642] usb 2-2: USB disconnect, device number 7
[ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
[ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 175.014984] usb 2-2: Product: HP USB Optical Mouse
[ 175.037886] usb 2-2: Manufacturer: PixArt
[ 175.061794] input: PixArt HP USB Optical Mouse as
/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse
[PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
Signed-off-by: Dave Young
---
drivers/hid/hid-ids.h |1 +
drivers/hid/usbhid/hid-quirks.c |1 +
2 files changed, 2 insertions(+)
--- linux-x86.orig/drivers/hid/hid-ids.h
+++ linux-x86/drivers/hid/hid-ids.h
@@ -535,6 +535,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A0x094a
#define USB_VENDOR_ID_HUION0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
--- linux-x86.orig/drivers/hid/usbhid/hid-quirks.c
+++ linux-x86/drivers/hid/usbhid/hid-quirks.c
@@ -99,6 +99,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE,
HID_QUIRK_ALWAYS_POLL },
+ { USB_VENDOR_ID_HP,
USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C007,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_C077,
HID_QUIRK_ALWAYS_POLL },
--
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 v2] Add support for Sony PS2 OHCI
Thank you for your review, Alan Stern,
> > With the patch above, the kernel successfully detects USB mass storage
> > devices. However, it also causes another crash:
> >
> > [ cut here ]
> > WARNING: CPU: 0 PID: 15 at ./include/linux/dma-mapping.h:530
> > hcd_buffer_free+0x130/0x200
> > Modules linked in:
> > CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.14.0+ #719
> > Workqueue: usb_hub_wq hub_event
> > Stack : 81f3b5b8 80402608 0003 000b 00f6 805611c4 81ccc280
> > 804f398c
> > 802ee5e0 804fd520 0009 0212 0001 10058400 81c09a38
> > 0001
> > 0003 000a 0002 0001
> >
> > 0001 3368 81c09878 81c09840 802ee5e0
> > 804fd520
> > 0009 0212 0001 fff3 0002
> > 805b
> > ...
> > Call Trace:
> > [<80021104>] show_stack+0x74/0x104
> > [<80036310>] __warn+0x114/0x11c
> > [<800363ac>] warn_slowpath_null+0x1c/0x30
> > [<802ee5e0>] hcd_buffer_free+0x130/0x200
> > [<802e56ec>] usb_hcd_unmap_urb_for_dma+0x160/0x16c
> > [<802e576c>] __usb_hcd_giveback_urb+0x54/0xf0
> > [<802f5d64>] finish_urb+0x98/0x138
> > [<802f716c>] ohci_work+0x14c/0x494
> > [<802f9878>] ohci_irq+0x13c/0x2e4
> > [<802e4e0c>] usb_hcd_irq+0x2c/0x44
> > [<8006366c>] __handle_irq_event_percpu+0x98/0x158
> > [<8006374c>] handle_irq_event_percpu+0x20/0x64
> > [<800637cc>] handle_irq_event+0x3c/0x70
> > [<80067024>] handle_level_irq+0xe4/0x120
> > [<80062d70>] generic_handle_irq+0x28/0x38
> > [<80409b58>] do_IRQ+0x18/0x24
> > ---[ end trace fa1f0201799de649 ]---
>
> This is caused by a deficiency in the DMA core: dma_free_coherent()
> wants interrupts to be enabled when it is called. I'm not sure how the
> other host controller drivers cope with this.
The OHCI drivers
drivers/usb/host/ohci-sm501.c and
drivers/usb/host/ohci-tmio.c
appear to be very similar to my driver. They both use HCD_LOCAL_MEM and
dma_declare_coherent_memory(). Curiously, though, they don't seem to disable
scatter-gather, or handle DMA in any special way, which I think is a bit odd.
I wonder how they could possibly avoid these two DMA crashes? (Especially
given the explicit WARN_ON_ONCE note in commit 4307a28eb012 "USB: EHCI: fix
NULL pointer dererence in HCDs that use HCD_LOCAL_MEM".)
One notable difference is that my driver does
hcd->regs = (void __iomem *)res->start;
where the other drivers use ioremap such that
hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
in the OHCI HCD probe function. (The hardware address logic is somewhat
involved and partially undocumented so there might be a good reason for this
difference in my driver.)
> 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.)
Fredrik
diff --git a/arch/mips/ps2/setup.c b/arch/mips/ps2/setup.c
index d9957711283e..d9caceacfaac 100644
--- a/arch/mips/ps2/setup.c
+++ b/arch/mips/ps2/setup.c
@@ -45,6 +45,29 @@ const char *get_system_type(void)
return "Sony PlayStation 2";
}
+#define IOP_REG_BASE 0xbf801460
+#define IOP_USB_BASE (IOP_REG_BASE + 0x1a0)
+
+static struct resource ps2_usb_ohci_resources[] = {
+ [0] = {
+ .start = IOP_USB_BASE,
+ .end= IOP_USB_BASE + 0xff,
+ .flags = IORESOURCE_MEM, /* 256 byte HCCA */
+ },
+ [1] = {
+ .start = IRQ_SBUS_USB,
+ .end= IRQ_SBUS_USB,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device ps2_usb_ohci_device = {
+ .name = "ps2_ohci",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(ps2_usb_ohci_resources),
+ .resource = ps2_usb_ohci_resources,
+};
+
void __init plat_mem_setup(void)
{
ps2_reset_init();
@@ -68,6 +91,10 @@ void __init plat_mem_setup(void)
set_io_port_base(CKSEG1);
}
+static struct platform_device *ps2_platform_devices[] __initdata = {
+ &ps2_usb_ohci_device,
+};
+
static int __init ps2_board_setup(void)
{
ps2dma_init();
@@ -85,6 +112,8 @@ static int __init ps2_board_setup(void)
if (load_module_firmware("ps2/dev9_dma.irx", 0) < 0)
pr_err("loading ps2/dev9_dma.irx failed\n");
+ platform_add_devices(ps2_platform_devices,
ARRAY_SIZE(ps2_platform_devices));
+
return 0;
}
arch_initcall(ps2_board_setup);
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index fa5692dec832..0f74d3420066 100644
--
Re: 4.14 dwc3 gadget mode panic
On Fri, 24 Nov 2017 15:55:02 +, Vincent Pelletier
wrote:
> write(6, "bla\n", 4)= -1 EINTR (Interrupted system call)
> --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=1931, si_uid=1000} ---
I discovered this is not the whole truth: it is not the interruption
itself which causes the issue, it is rather deallocating stuff as the
process is headed toward exiting which triggers the issue. Looks like
strace does not have time to print before things go south.
Compared to my original code, I then did 2 changes:
- Call io_destroy before closing any endpoint file.
This (alone, at least) does not improve the situation
- Cancelling AIO transfers before closing AIO context, itself happening
before closing any endpoint file.
This avoided the panic. Doing so, I noticed io_cancel returns -115,
aka -EINPROGRESS. But calling it a second time on the same transfer
then fails with -EINVAL, so it seems cancellation did succeed (not
very familiar with AIO). Maybe this confuses usb_f_fs.ko ?
Not sure why in original code I thought I should destroy AIO context
after closing endpoints (does not look right). I would expect it to
succeed, though, and not find any AIO transfer to cancel by that time.
Checking the first traceback in my first mail, am I right to read it as
io_destroy being the cause of AIO getting cancelled ?
[ 382.230770] ffs_aio_cancel+0x37/0x60 [usb_f_fs]
[ 382.230798] kiocb_cancel+0x31/0x40
[ 382.230822] free_ioctx_users+0x4d/0xd0 <- io_destroy, kernel-side ?
[ 382.230858] percpu_ref_switch_to_atomic_rcu+0x10a/0x130
[ 382.230881] ? percpu_ref_exit+0x40/0x40
[ 382.230904] rcu_process_callbacks+0x2b3/0x440
[ 382.230965] __do_softirq+0xf8/0x26b <- syscall entry point ?
Meaning closing the endpoints in userland left AIO requests behind...
Is this valid ?
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: [PATCH] [stable only]USB: fix buffer overflows with parsing CDC headers
On Thu, Nov 23, 2017 at 04:20:05PM +0100, Oliver Neukum wrote: > Parsing CDC headers a buffer overflow cannot just be prevented > by checking that the remainder of the buffer is longer than minimum > length. The size of the fields to be parsed must be figured in, too. > > In newer kernels this issue has been fixed at a central location with > > commit 2e1c42391ff2556387b3cb6308b24f6f65619feb > Author: Greg Kroah-Hartman > Date: Thu Sep 21 16:58:48 2017 +0200 > > USB: core: harden cdc_parse_cdc_header > > on anything older the parsing had not been centralised, so a separate > fix for each driver is necessary. > > Signed-off-by: Oliver Neukum > --- > drivers/net/usb/cdc_ether.c | 9 - > drivers/usb/class/cdc-acm.c | 2 +- > drivers/usb/class/cdc-wdm.c | 2 ++ > 3 files changed, 11 insertions(+), 2 deletions(-) What stable kernel(s) should this go to? 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: 4.14 dwc3 gadget mode panic
On Fri, 24 Nov 2017 15:10:55 +, Vincent Pelletier
wrote:
> It sadly does not help, though it does something: now serial output
> stops early (tried twice, happened twice):
>
> [ 103.274725] BUG: scheduling while atomic: swapper/1/0/0x0100
> [ 103.280990] 3 locks held by swapper/1/0:
> [ 103.280998] #0: (rcu_callback){}, at: []
> rcu_process_callbacks+0x260/0x440
> [ 103.281053] #1: (rcu_read_lock_sched){}, at: []
> percpu_ref_switch_to_atomic_rcu+0xb0/0x130
> [ 103.281097] #2: (&(&ctx->ctx_lock)->rlock){}, at: []
> free_ioctx_us
>
> So I do not get dropped to kdb...
I jumped to a conclusion here: re-building without proposed change I
get dropped to kdb, but output above it is sometimes truncated
(notice last line starting with timestamp). So there may be no causality
between truncated output and lack of kdb.
FWIW, I only replaced usb_f_fs.ko after rebuilding with the change.
Could it explain not reaching kdb ?
[ 2561.128669] BUG: scheduling while atomic: swapper/0/0/0x0100
[ 2561.134908] 4 locks held by swapper/0/0:
[ 2561.139065] #0: (rcu_callback){}, at: []
rcu_process_callbacks+0x260/0x440
[ 2561.147751] #1: (rcu_read_loc
Entering kdb (current=0xc1b8eb40, pid 0) on processor 0 Oops: (null)
due to oops @ 0xc1083ccd
CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.14.0-edison+ #117
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
task: c1b8eb40 task.stack: c1b7c000
EIP: enqueue_entity+0xb8d/0xd00
EFLAGS: 00210002 CPU: 0
EAX: 02ce EBX: 0007 ECX: 8ebf1e98 EDX:
ESI: fffbe9fd EDI: EBP: f6833e9c ESP: f6833e4c
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 80050033 CR2: 02ea CR3: 342c2000 CR4: 001006d0
Call Trace:
? __lock_is_held+0x3a/0x80
? __update_load_avg_se.isra.24+0x144/0x1e0
? __enqueue_entity+0x67/0x70
? enqueue_entity+0xb8a/0xd00
? __lock_is_held+0x3a/0x80
? __lock_is_held+0x3a/0x80
? try_to_wake_up+0x3cb/0x3e0
? try_to_wake_up+0x3cb/0x3e0
? wake_up_process+0x14/0x20
? __softirqentry_text_start+0x8/0x8
? do_softirq_own_stack+0x22/0x30
Code: 89 c2 b8 03 00 00 00 0f ac d9 14 e8 6e 40 03 00 8d b6 00 00 00 00 8b 45
f0 39 45 d8 74 0a 89 c2 8b 45 e4 e8 b6 7d ff ff 8b 45 f0 40 1c 01 00 00 00
8b 45 e4 83 78 08 01 0f 85 51 01 00 00 8b
[0]kdb>
Also, during above crash, I captured strace output (mixes process and
strace output, but should be easy to distinguish):
epoll_wait(8, [{EPOLLIN, {u32=0, u64=13802635209725706240}}], 1023, -1) = 1
write(2, "epoll: fd 0 got event 1", 23epoll: fd 0 got event 1) = 23
write(2, "\n", 1
) = 1
mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb76d6000
fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
read(0, "bla\n", 1048576) = 4
read(0, 0xb76d6020, 1047552)= -1 EAGAIN (Resource temporarily
unavailable)
mremap(0xb76d6000, 1052672, 4096, MREMAP_MAYMOVE) = 0xb76d6000
write(2, "sending", 7sending) = 7
write(2, " ", 1 )= 1
write(2, "4", 14)= 1
write(2, " ", 1 )= 1
write(2, "bytes", 5bytes)= 5
write(2, "\n", 1
) = 1
write(6, "bla\n", 4)= -1 EINTR (Interrupted system call)
--- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=1931, si_uid=1000} ---
--
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: 4.14 dwc3 gadget mode panic
On Fri, 24 Nov 2017 16:45:53 +0200, Felipe Balbi
wrote:
> no, it's not. This is because of our call to wait_event_lock_irq() in
> dwc3_gadget_ep_dequeue(). That call works fine in all other cases
> because dequeue is never called with IRQs disabled, apart from this one
> case in f_fs.c :-)
>
> Can you confirm that this helps:
>
> modified drivers/usb/gadget/function/f_fs.c
> @@ -1077,15 +1077,11 @@ static int ffs_aio_cancel(struct kiocb *kiocb)
>
> ENTER();
>
> - spin_lock_irq(&epfile->ffs->eps_lock);
> -
> if (likely(io_data && io_data->ep && io_data->req))
> value = usb_ep_dequeue(io_data->ep, io_data->req);
> else
> value = -EINVAL;
>
> - spin_unlock_irq(&epfile->ffs->eps_lock);
> -
> return value;
> }
>
It sadly does not help, though it does something: now serial output
stops early (tried twice, happened twice):
[ 103.274725] BUG: scheduling while atomic: swapper/1/0/0x0100
[ 103.280990] 3 locks held by swapper/1/0:
[ 103.280998] #0: (rcu_callback){}, at: []
rcu_process_callbacks+0x260/0x440
[ 103.281053] #1: (rcu_read_lock_sched){}, at: []
percpu_ref_switch_to_atomic_rcu+0xb0/0x130
[ 103.281097] #2: (&(&ctx->ctx_lock)->rlock){}, at: []
free_ioctx_us
So I do not get dropped to kdb...
--
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: 4.14 dwc3 gadget mode panic
Hi,
Vincent Pelletier writes:
> On Fri, 24 Nov 2017 16:10:17 +0200, Felipe Balbi
> wrote:
>> $ gdb vmlinux
>> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
>>
>>
>> what does that give you?
>
> Note: this is a different debugging session, different traceback, but
> same kernel.
>
> $ gdb ./vmlinux
> [...]
> (gdb) target remote /dev/ttyUSB0
> [...]
> (gdb) lx-symbols
> [...]
> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
> 0xf81b50ac is in dwc3_gadget_ep_dequeue (./include/linux/spinlock.h:342).
> 337 raw_spin_lock_nest_lock(spinlock_check(lock), nest_lock);
> \
> 338 } while (0)
> 339
> 340 static __always_inline void spin_lock_irq(spinlock_t *lock)
> 341 {
> 342 raw_spin_lock_irq(&lock->rlock);
> 343 }
> 344
> 345 #define spin_lock_irqsave(lock, flags) \
> 346 do {\
>
> Which is likely the spin_lock_irqsave call early in the function.
no, it's not. This is because of our call to wait_event_lock_irq() in
dwc3_gadget_ep_dequeue(). That call works fine in all other cases
because dequeue is never called with IRQs disabled, apart from this one
case in f_fs.c :-)
Can you confirm that this helps:
modified drivers/usb/gadget/function/f_fs.c
@@ -1077,15 +1077,11 @@ static int ffs_aio_cancel(struct kiocb *kiocb)
ENTER();
- spin_lock_irq(&epfile->ffs->eps_lock);
-
if (likely(io_data && io_data->ep && io_data->req))
value = usb_ep_dequeue(io_data->ep, io_data->req);
else
value = -EINVAL;
- spin_unlock_irq(&epfile->ffs->eps_lock);
-
return value;
}
--
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: 4.14 dwc3 gadget mode panic
On Fri, 24 Nov 2017 16:10:17 +0200, Felipe Balbi
wrote:
> $ gdb vmlinux
> (gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
>
>
> what does that give you?
Note: this is a different debugging session, different traceback, but
same kernel.
$ gdb ./vmlinux
[...]
(gdb) target remote /dev/ttyUSB0
[...]
(gdb) lx-symbols
[...]
(gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
0xf81b50ac is in dwc3_gadget_ep_dequeue (./include/linux/spinlock.h:342).
337 raw_spin_lock_nest_lock(spinlock_check(lock), nest_lock);
\
338 } while (0)
339
340 static __always_inline void spin_lock_irq(spinlock_t *lock)
341 {
342 raw_spin_lock_irq(&lock->rlock);
343 }
344
345 #define spin_lock_irqsave(lock, flags) \
346 do {\
Which is likely the spin_lock_irqsave call early in the function.
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: 4.14 dwc3 gadget mode panic
Hi,
Vincent Pelletier writes:
> Hello,
>
> I'm triggering a reproducible panic using a DWC3 in gadget mode
> (intel edison board). Built kernel is a 4.14 with all patches from
> Andy Shevchenko's tree for the edison (including ones to the dwc3 to
> skip EP1 & 8). It is available here:
> https://github.com/vpelletier/linux/tree/eds_4.14
>
> The setup is a rather simple test implementation for bidirectional
> piping:
> Test program is here (highlighted is the blocking call described below):
>
> https://github.com/vpelletier/python-functionfs/blob/da45cb2435b26e65d8385b67a7395be04a65461c/examples/usbcat/device.py#L134
>
> What seem to be the relevant pieces are:
> - at least one AIO transfers submitted for reading from EP2OUT
> - upon receiving data from stdin, a synchronous write happens on EP2IN,
> which blocks if host did not submit a transfer (normal)
> - SIGQUIT to interrupt the write while it's blocking
>
> A very short while after SIGQUIT, the kernel emits a BUG, which content
> and severity (dropping to kdb command line, or sometimes continuing
> seemingly normally), but seem to always be inside
> dwc3_gadget_ep_dequeue (2 traces below, where kernel survived and
> another boot where it panic'ed).
>
> Only writing without submitted AIO transfers does not cause any panic
> on interruption.
>
> What should I do to debug further ?
>
> Case where the kernel survived:
> [ 382.200896] BUG: scheduling while atomic: screen/1808/0x0100
> [ 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]
> [ 382.230160] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio
> bluetooth ecdh_generic brcmfmac brcmutil intel_powerclamp coretemp dwc3
> kvm_intel ulpi udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci
> aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd gpio_keys usbcore
> basincove_gpadc industrialio usb_common
> [ 382.230407] CPU: 1 PID: 1808 Comm: screen Not tainted 4.14.0-edison+ #117
> [ 382.230416] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS
> 542 2015.01.21:18.19.48
> [ 382.230425] Call Trace:
> [ 382.230438]
> [ 382.230466] dump_stack+0x47/0x62
> [ 382.230498] __schedule_bug+0x61/0x80
> [ 382.230522] __schedule+0x43/0x7a0
> [ 382.230587] schedule+0x5f/0x70
> [ 382.230625] dwc3_gadget_ep_dequeue+0x14c/0x270 [dwc3]
$ gdb vmlinux
(gdb) l *(dwc3_gadget_ep_dequeue + 0x14c)
what does that give you?
--
balbi
signature.asc
Description: PGP signature
RE: [RFC PATCH v2 6/7] typec: tcpm: Represent source supply through power_supply class
On 24 November 2017 12:19, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Nov 14, 2017 at 11:44:47AM +, Adam Thomson wrote:
> > diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> > index 78983e1..7c26c3d 100644
> > --- a/drivers/usb/typec/tcpm.c
> > +++ b/drivers/usb/typec/tcpm.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -277,6 +278,10 @@ struct tcpm_port {
> > u32 current_limit;
> > u32 supply_voltage;
> >
> > + /* Used to export TA voltage and current */
> > + struct power_supply *psy;
> > + struct power_supply_desc psy_desc;
> > +
> > u32 bist_request;
> >
> > /* PD state for Vendor Defined Messages */
> > @@ -1756,6 +1761,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> > int ret = -EINVAL;
> >
> > port->pps_data.supported = false;
> > + port->psy_desc.type = POWER_SUPPLY_TYPE_USB_PD;
> >
> > /*
> > * Select the source PDO providing the most power while staying within
> > @@ -1775,8 +1781,10 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> > mv = pdo_min_voltage(pdo);
> > break;
> > case PDO_TYPE_APDO:
> > - if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
> > + if (pdo_apdo_type(pdo) == APDO_TYPE_PPS) {
> > port->pps_data.supported = true;
> > + port->psy_desc.type =
> POWER_SUPPLY_TYPE_USB_PD_PPS;
> > + }
> > continue;
> > default:
> > tcpm_log(port, "Invalid PDO type, ignoring");
> > @@ -2248,6 +2256,9 @@ static void tcpm_reset_port(struct tcpm_port *port)
> > port->try_snk_count = 0;
> > port->supply_voltage = 0;
> > port->current_limit = 0;
> > + port->psy_desc.type = POWER_SUPPLY_TYPE_USB_TYPE_C;
>
> Is it OK to everybody that the type of the psy is changed like that?
> Hans?!
>
> We do have drivers that already change the type, for example
> drivers/power/supply/isp1704_charger.c, but what does the user space
> expect? The ABI for the power supply class was never documented I
> guess.
>
Hi Heikki,
Appreciate your time in reviewing this.
Yes, I actually saw that as an example when I considered this approach. I didn't
see anything obvious for this in the ABI documentation. Any ideas Sebastian?
What is user-space expectation for the 'type' property of a power_supply? I
assume having this dynamic is ok given existing drivers can already do something
like this, but would be good to have clarification.
> I'm not against changing the type, but I think that we should have an
> attribute file listing all supported types a psy can have if we go
> forward with this. Ideally the type file would just list them as space
> separated values, and show the current one with asterisk in front of
> it. The output would be similar we have with some of the other files
> under /sys/power, at least /sys/power/state, but that would break the
> ABI.
>
I added this as I wanted the user to know what was connected rather than
blindly trying to set the 'online' property to enable PPS, even if the attached
source partner didn't support this. As you say, am not sure we could change the
'TYPE' property as that to my knowledge has always been a single string.
Maybe the addition of a 'SUPPORTED_TYPES' property or something similar could
close this gap (as you eluded to), at least by providing a RO list of all
supported types? Another option would be to add a type which indicates the
supply supports multiple types, and then based on this we can read another
property which does as you suggest with multiple strings and one being
highlighted? Am certainly open to discussion on this.
--
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
4.14 dwc3 gadget mode panic
Hello,
I'm triggering a reproducible panic using a DWC3 in gadget mode
(intel edison board). Built kernel is a 4.14 with all patches from
Andy Shevchenko's tree for the edison (including ones to the dwc3 to
skip EP1 & 8). It is available here:
https://github.com/vpelletier/linux/tree/eds_4.14
The setup is a rather simple test implementation for bidirectional
piping:
Bus 001 Device 105: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
Couldn't open device, some information will be missing
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x1d6b Linux Foundation
idProduct 0x0104 Multifunction Composite Gadget
bcdDevice4.14
iManufacturer 1
iProduct2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Test program is here (highlighted is the blocking call described below):
https://github.com/vpelletier/python-functionfs/blob/da45cb2435b26e65d8385b67a7395be04a65461c/examples/usbcat/device.py#L134
What seem to be the relevant pieces are:
- at least one AIO transfers submitted for reading from EP2OUT
- upon receiving data from stdin, a synchronous write happens on EP2IN,
which blocks if host did not submit a transfer (normal)
- SIGQUIT to interrupt the write while it's blocking
A very short while after SIGQUIT, the kernel emits a BUG, which content
and severity (dropping to kdb command line, or sometimes continuing
seemingly normally), but seem to always be inside
dwc3_gadget_ep_dequeue (2 traces below, where kernel survived and
another boot where it panic'ed).
Only writing without submitted AIO transfers does not cause any panic
on interruption.
What should I do to debug further ?
Case where the kernel survived:
[ 382.200896] BUG: scheduling while atomic: screen/1808/0x0100
[ 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]
[ 382.230160] Modules linked in: usb_f_fs libcomposite configfs bnep btsdio
bluetooth ecdh_generic brcmfmac brcmutil intel_powerclamp coretemp dwc3
kvm_intel ulpi udc_core kvm irqbypass crc32_pclmul crc32c_intel pcbc dwc3_pci
aesni_intel aes_i586 crypto_simd cryptd ehci_pci ehci_hcd gpio_keys usbcore
basincove_gpadc industrialio usb_common
[ 382.230407] CPU: 1 PID: 1808 Comm: screen Not tainted 4.14.0-edison+ #117
[ 382.230416] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542
2015.01.21:18.19.48
[ 382.230425] Call Trace:
[ 382.230438]
[ 382.230466] dump_stack+0x47/0x62
[ 382.230498] __schedule_bug+0x61/0x80
[ 382.230522] __schedule+0x43/0x7a0
[ 382.230587] schedule+0x5f/0x70
[ 382.230625] dwc3_gadget_ep_dequeue+0x14c/0x270 [dwc3]
[ 382.230669] ? do_wait_intr_irq+0x70/0x70
[ 382.230724] usb_ep_dequeue+0x19/0x90 [udc_core]
[ 382.230770] ffs_aio_cancel+0x37/0x60 [usb_f_fs]
[ 382.230798] kiocb_cancel+0x31/0x40
[ 382.230822] free_ioctx_users+0x4d/0xd0
[ 382.230858] percpu_ref_switch_to_atomic_rcu+0x10a/0x130
[ 382.230881] ? percpu_ref_exit+0x40/0x40
[ 382.230904] rcu_process_callbacks+0x2b3/0x440
[ 382.230965] __do_softirq+0xf8/0x26
[PATCH] USB: atm: use setup_timer instead of init_timer
From: Colin Ian King
Use setup_timer function instead of initializing timer with the
function and data fields.
Signed-off-by: Colin Ian King
---
drivers/usb/atm/usbatm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/atm/usbatm.c b/drivers/usb/atm/usbatm.c
index 044264aa1f96..ef456cd0d3ab 100644
--- a/drivers/usb/atm/usbatm.c
+++ b/drivers/usb/atm/usbatm.c
@@ -998,9 +998,8 @@ static void usbatm_init_channel(struct usbatm_channel
*channel)
{
spin_lock_init(&channel->lock);
INIT_LIST_HEAD(&channel->list);
- channel->delay.function = usbatm_tasklet_schedule;
- channel->delay.data = (unsigned long) &channel->tasklet;
- init_timer(&channel->delay);
+ setup_timer(&channel->delay, usbatm_tasklet_schedule,
+ (unsigned long)&channel->tasklet);
}
int usbatm_usb_probe(struct usb_interface *intf, const struct usb_device_id
*id,
--
2.14.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: [RFC PATCH v2 6/7] typec: tcpm: Represent source supply through power_supply class
Hi,
On Tue, Nov 14, 2017 at 11:44:47AM +, Adam Thomson wrote:
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 78983e1..7c26c3d 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -277,6 +278,10 @@ struct tcpm_port {
> u32 current_limit;
> u32 supply_voltage;
>
> + /* Used to export TA voltage and current */
> + struct power_supply *psy;
> + struct power_supply_desc psy_desc;
> +
> u32 bist_request;
>
> /* PD state for Vendor Defined Messages */
> @@ -1756,6 +1761,7 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> int ret = -EINVAL;
>
> port->pps_data.supported = false;
> + port->psy_desc.type = POWER_SUPPLY_TYPE_USB_PD;
>
> /*
>* Select the source PDO providing the most power while staying within
> @@ -1775,8 +1781,10 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port)
> mv = pdo_min_voltage(pdo);
> break;
> case PDO_TYPE_APDO:
> - if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
> + if (pdo_apdo_type(pdo) == APDO_TYPE_PPS) {
> port->pps_data.supported = true;
> + port->psy_desc.type =
> POWER_SUPPLY_TYPE_USB_PD_PPS;
> + }
> continue;
> default:
> tcpm_log(port, "Invalid PDO type, ignoring");
> @@ -2248,6 +2256,9 @@ static void tcpm_reset_port(struct tcpm_port *port)
> port->try_snk_count = 0;
> port->supply_voltage = 0;
> port->current_limit = 0;
> + port->psy_desc.type = POWER_SUPPLY_TYPE_USB_TYPE_C;
Is it OK to everybody that the type of the psy is changed like that?
Hans?!
We do have drivers that already change the type, for example
drivers/power/supply/isp1704_charger.c, but what does the user space
expect? The ABI for the power supply class was never documented I
guess.
I'm not against changing the type, but I think that we should have an
attribute file listing all supported types a psy can have if we go
forward with this. Ideally the type file would just list them as space
separated values, and show the current one with asterisk in front of
it. The output would be similar we have with some of the other files
under /sys/power, at least /sys/power/state, but that would break the
ABI.
Thanks,
--
heikki
--
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: usbip port number limits
> De: "Yuyang Du"
> Para: "Juan Zea"
> CC: "Shuah Khan" , sh...@kernel.org, "Bjørn Mork"
> , linux-usb@vger.kernel.org, "Valentina Manea"
>
> Enviados: Viernes, 24 de Noviembre 2017 8:22:44
> Asunto: Re: usbip port number limits
>
> On Wed, Nov 22, 2017 at 09:38:27AM +0100, Juan Zea wrote:
> > I don't come up with any more detail... anything I'm missing?
>
> Hi Juan,
>
> Thank you so much for your patience. Really appreciate it.
>
> I came up with the following patch, with which at my side the
> BUG doesn't happen again with both a (low speed ) mouse and a
> (high speed) stick attached at the client over localhost server.
>
> Would you be able to test it at your side?
>
> I applied the patch right on top of the commit b891245bff7958
> ("usbip: vhci-hcd: Clean up the code by adding a new macro").
> Anyway, the patch is pretty trivial.
>
> Thanks,
> Yuyang
>
Hi Yuyang,
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 :)
I've also checked the same patch can be applied to kernel master and it works.
So... is that the solution?
Regards,
Juan
Juan Antonio Zea Herranz
Proyectos y consultoría | Qindel Group
E: juan@qindel.com
T: +34 91 766 24 21
M: +34 637 74 63 09
W: qindel.com
- Mensaje original -
--
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 64c3860..732edaf 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1112,7 +1112,6 @@ static int hcd_name_to_id(const char *name)
static int vhci_setup(struct usb_hcd *hcd)
{
struct vhci *vhci = *((void **)dev_get_platdata(hcd->self.controller));
- hcd->self.sg_tablesize = ~0;
if (usb_hcd_is_primary_hcd(hcd)) {
vhci->vhci_hcd_hs = hcd_to_vhci_hcd(hcd);
vhci->vhci_hcd_hs->vhci = vhci;
--
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 v3] typec: tcpm: fusb302: Resolve out of order messaging events
On Tue, Nov 21, 2017 at 02:12:12PM +, Adam Thomson wrote:
> The expectation in the FUSB302 driver is that a TX_SUCCESS event
> should occur after a message has been sent, but before a GCRCSENT
> event is raised to indicate successful receipt of a message from
> the partner. However in some circumstances it is possible to see
> the hardware raise a GCRCSENT event before a TX_SUCCESS event
> is raised. The upshot of this is that the GCRCSENT handling portion
> of code ends up reporting the GoodCRC message to TCPM because the
> TX_SUCCESS event hasn't yet arrived to trigger a consumption of it.
> When TX_SUCCESS is then raised by the chip it ends up consuming the
> actual message that was meant for TCPM, and this incorrect sequence
> results in a hard reset from TCPM.
>
> To avoid this problem, this commit updates the message reading
> code to check whether a GoodCRC message was received or not. Based
> on this check it will either report that the previous transmission
> has completed or it will pass the msg data to TCPM for futher
> processing. This way the incorrect ordering of the events no longer
> matters.
>
> Signed-off-by: Adam Thomson
FWIW:
Acked-by: Heikki Krogerus
> ---
>
> Changes in v3:
> - Always read from FIFO on TX_SUCCES and GCRCSENT events, but decision on how
>to report to TCPM is no longer based on these event types but instead on
> type
>of message read in from FIFO.
>
> Changes in v2:
> - Remove erroneous extended header check
>
> Patch is based on Linux next-20171114 to include move out of staging.
>
> drivers/usb/typec/fusb302/fusb302.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/typec/fusb302/fusb302.c
> b/drivers/usb/typec/fusb302/fusb302.c
> index 72cb060..d200085 100644
> --- a/drivers/usb/typec/fusb302/fusb302.c
> +++ b/drivers/usb/typec/fusb302/fusb302.c
> @@ -1543,6 +1543,21 @@ static int fusb302_pd_read_message(struct fusb302_chip
> *chip,
> fusb302_log(chip, "PD message header: %x", msg->header);
> fusb302_log(chip, "PD message len: %d", len);
>
> + /*
> + * Check if we've read off a GoodCRC message. If so then indicate to
> + * TCPM that the previous transmission has completed. Otherwise we pass
> + * the received message over to TCPM for processing.
> + *
> + * We make this check here instead of basing the reporting decision on
> + * the IRQ event type, as it's possible for the chip to report the
> + * TX_SUCCESS and GCRCSENT events out of order on occasion, so we need
> + * to check the message type to ensure correct reporting to TCPM.
> + */
> + if ((!len) && (pd_header_type_le(msg->header) == PD_CTRL_GOOD_CRC))
> + tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
> + else
> + tcpm_pd_receive(chip->tcpm_port, msg);
> +
> return ret;
> }
>
> @@ -1650,13 +1665,12 @@ static irqreturn_t fusb302_irq_intn(int irq, void
> *dev_id)
>
> if (interrupta & FUSB_REG_INTERRUPTA_TX_SUCCESS) {
> fusb302_log(chip, "IRQ: PD tx success");
> - /* read out the received good CRC */
> ret = fusb302_pd_read_message(chip, &pd_msg);
> if (ret < 0) {
> - fusb302_log(chip, "cannot read in GCRC, ret=%d", ret);
> + fusb302_log(chip,
> + "cannot read in PD message, ret=%d", ret);
> goto done;
> }
> - tcpm_pd_transmit_complete(chip->tcpm_port, TCPC_TX_SUCCESS);
> }
>
> if (interrupta & FUSB_REG_INTERRUPTA_HARDRESET) {
> @@ -1677,7 +1691,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void
> *dev_id)
> "cannot read in PD message, ret=%d", ret);
> goto done;
> }
> - tcpm_pd_receive(chip->tcpm_port, &pd_msg);
> }
> done:
> mutex_unlock(&chip->lock);
Thanks,
--
heikki
--
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] typec: fusb302: Use dev_err during probe
On Fri, Nov 24, 2017 at 12:03:16AM +0100, Mats Karrman wrote: > If probe fails, fusb302_debugfs_exit is called making it impossible > to view any logs so use normal dev_err for any error messages during > probe. > > Signed-off-by: Mats Karrman Acked-by: Heikki Krogerus Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: gadget: udc: fix spelling mistake "unexpect" -> "unexpected"
From: Colin Ian King
Trival fix to spelling mistake in ERR message
Signed-off-by: Colin Ian King
---
drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/udc/fsl_udc_core.c
index d606d4f13098..e5b4ee96c4bf 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1543,7 +1543,7 @@ static void ep0_req_complete(struct fsl_udc *udc, struct
fsl_ep *ep0,
udc->ep0_state = WAIT_FOR_SETUP;
break;
case WAIT_FOR_SETUP:
- ERR("Unexpect ep0 packets\n");
+ ERR("Unexpected ep0 packets\n");
break;
default:
ep0stall(udc);
--
2.14.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] r8152: disable rx checksum offload on Dell TB dock
> Also the MAC address is different, can you just trigger off of Dell's > MAC address space instead of the address space of the dongle device? A really good idea, never thought of this. Thanks for the hint :) Still, I need to ask Dell folks to get all the answers. Kai-Heng -- 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] r8152: disable rx checksum offload on Dell TB dock
> On 24 Nov 2017, at 4:28 PM, Greg KH wrote: > > The bcdDevice is different between the dock device and the "real" > device, why not use that? Yea, I’ll poke around and see if bcdDevice alone can be a good predicate. > Then there is still a bug. Who as ASMedia is working on this, have they > posted anything to the linux-usb mailing list about it? I think they are doing this internally. I’ll advice them to ask questions here if they encounter any problem. > Maybe. Have you tried using usbmon to see what the data streams are for > the two devices and where they have problems and diverge? Is the dock > device doing something different in response to something from the host > that the "real" device does not do? No I haven’t. Not really sure how do debug network packets over USB. I’ll do some research on the topic. Kai-Heng -- 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] r8152: disable rx checksum offload on Dell TB dock
On Fri, Nov 24, 2017 at 09:28:05AM +0100, Greg KH wrote: > On Fri, Nov 24, 2017 at 11:44:02AM +0800, Kai Heng Feng wrote: > > > > > > > On 23 Nov 2017, at 5:24 PM, Greg KH wrote: > > > > > > On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote: > > >> > > >> What I want to do here is to finding this connection: > > >> Realtek r8153 <-> SMSC hub (USD ID: 0424:5537) <-> > > >> ASMedia XHCI controller (PCI ID: 1b21:1142). > > >> > > >> Is there a safer way to do this? > > > > > > Nope! You can't do that at all from within a USB driver, sorry. As you > > > really should not care at all :) > > > > Got it :) > > > > The r8153 in Dell TB dock has version information, RTL_VER_05. > > We can use it to check for workaround, but many working RTL_VER_05 devices > > will also be affected. > > Do you think it’s an acceptable compromise? > > I think all of the users of this device that is working just fine for > them would not like that to happen :( > > > >> I have a r8153 <-> USB 3.0 dongle which work just fine. I can’t find any > > >> information to differentiate them. Hence I want to use the connection to > > >> identify if r8153 is on a Dell TB dock. > > > > > > Are you sure there is nothing different in the version or release number > > > of the device? 'lsusb -v' shows the exact same information for both > > > devices? > > > > Yes. I attached `lsusb -v` for r8153 on Dell TB dock, on a RJ45 <-> USB 3.0 > > dongle, > > and on a RJ45 <-> USB Type-C dongle. > > The bcdDevice is different between the dock device and the "real" > device, why not use that? Also the MAC address is different, can you just trigger off of Dell's MAC address space instead of the address space of the dongle device? 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: [PATCH] r8152: disable rx checksum offload on Dell TB dock
On Fri, Nov 24, 2017 at 11:44:02AM +0800, Kai Heng Feng wrote: > > > > On 23 Nov 2017, at 5:24 PM, Greg KH wrote: > > > > On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote: > >> > >> What I want to do here is to finding this connection: > >> Realtek r8153 <-> SMSC hub (USD ID: 0424:5537) <-> > >> ASMedia XHCI controller (PCI ID: 1b21:1142). > >> > >> Is there a safer way to do this? > > > > Nope! You can't do that at all from within a USB driver, sorry. As you > > really should not care at all :) > > Got it :) > > The r8153 in Dell TB dock has version information, RTL_VER_05. > We can use it to check for workaround, but many working RTL_VER_05 devices > will also be affected. > Do you think it’s an acceptable compromise? I think all of the users of this device that is working just fine for them would not like that to happen :( > >> I have a r8153 <-> USB 3.0 dongle which work just fine. I can’t find any > >> information to differentiate them. Hence I want to use the connection to > >> identify if r8153 is on a Dell TB dock. > > > > Are you sure there is nothing different in the version or release number > > of the device? 'lsusb -v' shows the exact same information for both > > devices? > > Yes. I attached `lsusb -v` for r8153 on Dell TB dock, on a RJ45 <-> USB 3.0 > dongle, > and on a RJ45 <-> USB Type-C dongle. The bcdDevice is different between the dock device and the "real" device, why not use that? > >> Yes. From what I know, ASMedia is working on it, but not sure how long it > >> will take. In the meantime, I’d like to workaround this issue for the > >> users. > > > > Again, it's a host controller bug, it should be fixed there, don't try > > to paper over the real issue in different individual drivers. > > > > I think I've seen various patches on the linux-usb list for this > > controller already, have you tried them? > > Yes. These patches are all in mainline Linux now. Then there is still a bug. Who as ASMedia is working on this, have they posted anything to the linux-usb mailing list about it? > >> Actually no. > >> I just plugged r8153 dongle into the same hub, surprisingly the issue > >> doesn’t happen in this scenario. > > > > Then something seems to be wrong with the device itself, as that would > > be the same exact electrical/logical path, right? > > I have no idea why externally plugged one doesn’t have this issue. > Maybe it’s related how it’s wired inside the Dell TB dock... Maybe. Have you tried using usbmon to see what the data streams are for the two devices and where they have problems and diverge? Is the dock device doing something different in response to something from the host that the "real" device does not do? 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
