Re: Fibocom L831-EAU and cdc_mbim

[Andreas Böhler]

On 18/09/17 22:18, Bjørn Mork wrote:
> Andreas Böhler  writes:
>>
>> I can also provide you with Wireshark USB traces, if that helps?
> 
> It might help. We are obviously interacting badly with the firmware.
> Seeing where and how it stops would be useful.

Attached are two Wireshark traces, I hope that I captured everything
relevant:

1. wwan_init_connect_failed.pcapng.gz
2. wwan_reset_init_connect_success.pcapng.gz

I disabled everything Modem-related (i.e. ModemManager), I blacklisted
the cdc* modules then I restarted the machine. The first trace was taken
directly after boot. I loaded the modules and I tried to enable
ModemManager and to connect to the Internet - it failed.

The second trace was taken after disabling ModemManager and sending
"AT+CFUN=15" to the device, thus resetting it. I then enabled
ModemManager and connected to the Internet - which succeeded.

Thanks,
Andreas


wwan_init_connect_failed.pcapng.gz
Description: application/gzip


wwan_reset_init_connect_success.pcapng.gz
Description: application/gzip

Re: Fibocom L831-EAU and cdc_mbim

[Bjørn Mork]

Andreas Böhler  writes:

> Unfortunately, it doesn't change anything. I applied the patch,
> recompiled the kernel (it updated to 4.13.2 at the same time), rebooted
> and upon connecting, I can see the 'cdc_mbim 1-6:1.0: nonzero urb status
> received: -EPIPE' message again.

Thanks for testing. Then I'll rule out that theory.  I guess that's
mostly good, since it didn't make much sense :-)

> What makes it work for this session only is the following (also works
> without your patch, though):
>
>   * connect to /dev/ttyACM0 using a terminal emulator (PuTTY in my case)
>   * send AT+CFUN=15 to reset the modem
>
> Then, the device re-appears as /dev/cdc-wdm1 (instead of /dev/cdc-wdm0)
> and connecting to the web is possible. If I then disable and re-enable
> the modem (in this case, using NetworkManager/ModemManager), the nonzero
> urb status message reappears. I can make it work again by resetting the
> modem a second time (and stopping ModemManager before the reset,
> starting it again after the reset).
>
> I can also provide you with Wireshark USB traces, if that helps?

It might help. We are obviously interacting badly with the firmware.
Seeing where and how it stops would be useful.

What I don't understand is why the -EPIPE error is permanent.  It is an
indication from the firmware that there was no data to read (which I
believe is a frmware bug, but whatever..).  But the stall should be
cleared on the next read. Unless the firmware decides to stop sending
notifications too?  Don't know why it would do that, though.

I am just so lost here...



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: Yet another Seagate quirk for unusual_uas.h

[Alan Stern]

On Mon, 18 Sep 2017, Kris Lindgren wrote:

> So I upgrade to 17.04 which is using the 4.10 kernel.
> 
> Without any modification the filesystem fails to mount.
> 
> Unloading the usb_storage module and reloading it with
> quirks=0bc2:3332:w allows the drive to be succesfully mounted and used
> without any errors.

Okay, so it looks like what you need is the patch below.  Let me know 
if it fixes the problem.

Alan Stern



Index: usb-4.x/drivers/usb/storage/unusual_devs.h
===
--- usb-4.x.orig/drivers/usb/storage/unusual_devs.h
+++ usb-4.x/drivers/usb/storage/unusual_devs.h
@@ -1459,6 +1459,13 @@ UNUSUAL_DEV( 0x0bc2, 0x3010, 0x, 0x0
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_SANE_SENSE ),
 
+/* Reported by Kris Lindgren  */
+UNUSUAL_DEV( 0x0bc2, 0x3332, 0x, 0x,
+   "Seagate",
+   "External",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_NO_WP_DETECT ),
+
 UNUSUAL_DEV(  0x0d49, 0x7310, 0x, 0x,
"Maxtor",
"USB to SATA",

--
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 v2] USB: serial: cp210x: add support for ELV TFD500

[Andreas Engel]

Add the USB device id for the ELV TFD500 data logger.

Signed-off-by: Andreas Engel 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 2d945c9f975c..bd8574ca32aa 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -177,6 +177,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
{ USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */
+   { USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */
{ USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */
{ USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */
{ USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */
-- 
2.13.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: Yet another Seagate quirk for unusual_uas.h

[Kris Lindgren]

On Mon, Sep 18, 2017 at 11:05 AM, Alan Stern  wrote:
> On Mon, 18 Sep 2017, Kris Lindgren wrote:
>
>> >> What happens if you plug the disk drive into a regular Linux desktop
>> >> computer?  Remember, if an unusual_uas.h entry is added, it will affect
>> >> those machines too.
>> >
>> > I will need to get back to you on this.  All of my other machines
>> > running linux, only have usb2.0 hubs.  They are also haven't been used
>> > in some time and are running older versions of Ubuntu.
>>
>> I upgraded a machine to the latest Ubuntu LTS distro - which is using
>> the 4.4 kernel
>>
>> When plugging in the drive without any modification, the drive fails to 
>> mount.
>> Dmesg output:
>> [  378.353553] usb 2-1.3: new high-speed USB device number 3 using ehci-pci
>> [  378.489981] usb 2-1.3: New USB device found, idVendor=0bc2, idProduct=3332
>> [  378.489985] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [  378.489987] usb 2-1.3: Product: External
>> [  378.489989] usb 2-1.3: Manufacturer: Seagate
>> [  378.489990] usb 2-1.3: SerialNumber: 2GHP5NM9
>> [  378.650153] usb-storage 2-1.3:1.0: USB Mass Storage device detected
>> [  378.650267] scsi host6: usb-storage 2-1.3:1.0
>> [  378.650359] usbcore: registered new interface driver usb-storage
>> [  378.684653] usbcore: registered new interface driver uas
>> [  379.651163] scsi 6:0:0:0: Direct-Access Seagate  External
>>   SG12 PQ: 0 ANSI: 4
>> [  379.651892] sd 6:0:0:0: Attached scsi generic sg2 type 0
>> [  379.652324] sd 6:0:0:0: [sdb] 3907029164 512-byte logical blocks:
>> (2.00 TB/1.82 TiB)
>> [  379.653077] sd 6:0:0:0: [sdb] Write Protect is off
>> [  379.653081] sd 6:0:0:0: [sdb] Mode Sense: 1c 00 00 00
>> [  379.654529] sd 6:0:0:0: [sdb] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [  379.723781]  sdb: sdb1
>> [  379.726584] sd 6:0:0:0: [sdb] Attached SCSI disk
>> [  379.907727] sd 6:0:0:0: [sdb] tag#0 FAILED Result:
>> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
>> [  379.907737] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error
>> [current] [descriptor]
>> [  379.907741] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense
>> information
>> [  379.907747] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass
>> through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
>> [  380.008600] sd 6:0:0:0: [sdb] tag#0 FAILED Result:
>> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
>> [  380.008608] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error
>> [current] [descriptor]
>> [  380.008611] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense
>> information
>> [  380.008616] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass
>> through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00
>> [  380.426654] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK
>> driverbyte=DRIVER_SENSE
>> [  380.426662] sd 6:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current]
>> [  380.42] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Invalid field in cdb
>> [  380.426670] sd 6:0:0:0: [sdb] tag#0 CDB: Synchronize Cache(10) 35
>> 00 00 00 00 00 00 00 00 00
>> [  380.426677] blk_update_request: critical target error, dev sdb, sector 0
>> [  380.426692] JBD2: recovery failed
>> [  380.426698] EXT4-fs (sdb1): error loading journal
>>
>> kernel version is:  4.4.0-93-generic
>
> And if you use the w quirk flag?

So I upgrade to 17.04 which is using the 4.10 kernel.

Without any modification the filesystem fails to mount.

Unloading the usb_storage module and reloading it with
quirks=0bc2:3332:w allows the drive to be succesfully mounted and used
without any errors.

[  168.613814] usb 2-1.3: new high-speed USB device number 3 using ehci-pci
[  168.746541] usb 2-1.3: New USB device found, idVendor=0bc2, idProduct=3332
[  168.746544] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[  168.746546] usb 2-1.3: Product: External
[  168.746548] usb 2-1.3: Manufacturer: Seagate
[  168.746550] usb 2-1.3: SerialNumber: 2GHP5NM9
[  168.847161] usb-storage 2-1.3:1.0: USB Mass Storage device detected
[  168.847367] usb-storage 2-1.3:1.0: Quirks match for vid 0bc2 pid 3332: 200
[  168.847429] scsi host6: usb-storage 2-1.3:1.0
[  168.847575] usbcore: registered new interface driver usb-storage
[  168.876249] usbcore: registered new interface driver uas
[  169.859397] scsi 6:0:0:0: Direct-Access Seagate  External
  SG12 PQ: 0 ANSI: 4
[  169.860378] sd 6:0:0:0: Attached scsi generic sg2 type 0
[  169.860932] sd 6:0:0:0: [sdb] 3907029164 512-byte logical blocks:
(2.00 TB/1.82 TiB)
[  169.860937] sd 6:0:0:0: [sdb] Assuming Write Enabled
[  169.860942] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[  169.926892]  sdb: sdb1
[  169.928163] sd 6:0:0:0: [sdb] Attached SCSI disk
[  170.117663] sd 6:0:0:0: [sdb] tag#0 FAILED Result:
hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  170.117669] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error
[current] [descriptor]
[  170.117671] sd 6:0:0:0: [sdb] tag#0 

Re: usb/core: slab-out-of-bounds in usb_set_configuration

[Greg Kroah-Hartman]

On Mon, Sep 18, 2017 at 07:22:24PM +0200, Andrey Konovalov wrote:
> Hi!
> 
> I've got the following crash while fuzzing the kernel with syzkaller.
> 
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
> 
> It seems there's no proper size check of a
> USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the
> size is >= 2 in usb_parse_configuration(), so find_iad() might do
> out-of-bounds access to intf_assoc->bInterfaceCount.

Ah, nice catch!

Does the patch below fix this?

thanks,

greg k-h

---

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 4be52c602e9b..a3dbac1938ec 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -643,15 +643,23 @@ static int usb_parse_configuration(struct usb_device 
*dev, int cfgidx,
 
} else if (header->bDescriptorType ==
USB_DT_INTERFACE_ASSOCIATION) {
+   struct usb_interface_assoc_descriptor *d;
+
+   d = (struct usb_interface_assoc_descriptor *)header;
+   if (d->bLength < USB_DT_INTERFACE_ASSOCIATION_SIZE) {
+   dev_warn(ddev,
+"config %d has an invalid interface 
association descriptor of length %d, skipping\n",
+cfgno, d->bLength);
+   continue;
+   }
+
if (iad_num == USB_MAXIADS) {
dev_warn(ddev, "found more Interface "
   "Association Descriptors "
   "than allocated for in "
   "configuration %d\n", cfgno);
} else {
-   config->intf_assoc[iad_num] =
-   (struct usb_interface_assoc_descriptor
-   *)header;
+   config->intf_assoc[iad_num] = d;
iad_num++;
}
 
diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index ce1169af39d7..2a5d63040a0b 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -780,6 +780,7 @@ struct usb_interface_assoc_descriptor {
__u8  iFunction;
 } __attribute__ ((packed));
 
+#define USB_DT_INTERFACE_ASSOCIATION_SIZE  8
 
 /*-*/
 
--
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 7/8] xhci: set missing SuperSpeedPlus Link Protocol bit in roothub descriptor

[Sergei Shtylyov]

Hello!

  Only some grammar nits, could prolly be fixed when applying...

On 09/18/2017 05:39 PM, Mathias Nyman wrote:


A SuperSpeedPlus roothub needs to have the Link Protocol (LP) bit set in
the bmSublinkSpeedAttr[] entry of a SuperSpeedPlus descriptor.

If the xhci controller has an optional Protocol Speed ID (PSI) table then
that will be used as a base to create the roothub SuperSpeedPlus
descriptor.
The PSI table does not however necessary contain the LP bit so we need


   Necessarily.


to set it manually.

Check the psi speed and set LP bit if speed is 10Gbps or higher.
We're not setting it for 5 to 10Gbps as USB 3.1 specification always
mention SuperSpeedPlus for 10Gbps or higher, and some SSIC USB 3.0 speeds


   Mentions.


can be over 5Gbps, such as SSIC-G3B-L1 at 5830 Mbps

Cc:  # 4.6+
Signed-off-by: Mathias Nyman 

[...]

MNR, 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: Fibocom L831-EAU and cdc_mbim

[Andreas Böhler]

On 18/09/17 12:27, Bjørn Mork wrote:
> Andreas Böhler  writes:
> 
>> I recently bought a Thinkpad T470 notebook and added the Fibocom
>> L831-EAU WWAN card. It's mbim-based, but unfortunately I can't get it
>> to work correctly. In fact I'm experiencing similar issues to Patrick
>> Chilton, who reported this behaviour a few months ago also on this
>> list: https://www.spinics.net/lists/linux-usb/msg158286.html
>>
>> After a new boot, the card works for me for a few minutes, then all
>> transfers stall. Finally, I receive the infamous 'cdc_mbim 1-6:1.0:
>> nonzero urb status received: -EPIPE' message in my system log.
>>
>> I also tried to disable MBIM by adding an option to modprobe. During
>> connect, pppd then just hangs up (again similar to what Patrick
>> Chilton experienced).
>>
>> I'm on Arch Linux and Kernel 4.12.13, I tried with and without
>> NetworkManager/ModemManager.
>>
>> Any ideas how I might be able to debug this?
> 
> Are you able to test the attached patch?  It should apply cleanly to any
> of the 4.9, 4.12 and 4.13 stable trees.

yes, of course!

> Let me just admit that this is a long shot.  I don't actually understand
> what happens here.  But I believe the problem started appearing with
> v4.9, which had two patches touching this part of the driver in
> suspicious ways.  One of those patches have already been reverted due to
> other issues.  But the second is still present.  And I can't see
> anything else which could possibly explain the problems.
> 
> If you can test this patch, then we can either confirm or refute this
> theory.

Unfortunately, it doesn't change anything. I applied the patch,
recompiled the kernel (it updated to 4.13.2 at the same time), rebooted
and upon connecting, I can see the 'cdc_mbim 1-6:1.0: nonzero urb status
received: -EPIPE' message again.

What makes it work for this session only is the following (also works
without your patch, though):

  * connect to /dev/ttyACM0 using a terminal emulator (PuTTY in my case)
  * send AT+CFUN=15 to reset the modem

Then, the device re-appears as /dev/cdc-wdm1 (instead of /dev/cdc-wdm0)
and connecting to the web is possible. If I then disable and re-enable
the modem (in this case, using NetworkManager/ModemManager), the nonzero
urb status message reappears. I can make it work again by resetting the
modem a second time (and stopping ModemManager before the reset,
starting it again after the reset).

I can also provide you with Wireshark USB traces, if that helps?

Andreas
--
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: serial: cp210x: add support for ELV TFD500

[Andreas Engel]

On Mon, 18 Sep 2017 10:23:16 +0200, Johan Hovold wrote:
> On Sun, Sep 03, 2017 at 12:04:40PM +0200, Andreas Engel wrote:
>> Add the USB device id for the ELV TFD500 data logger.
>>
>> [...]
> 
> This patch is whitespace damaged (tabs replaced with spaces) and does
> not apply.
> 
> Take a look at git-send-email, and please try sending it to yourself
> first to make sure your mail setup no longer corrupts the patch.
> 
> Thanks,
> Johan
> 
Oops, sorry. Sent v2.

Regards
Andreas
--
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

usb/hid: slab-out-of-bounds read in usbhid_parse

[Andrey Konovalov]

Hi!

I've got the following crash while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

It seems that there's no proper check on the hdesc->bNumDescriptors
value in usbhid_parse(). it iterates over hdesc->desc and accesses
hdesc->desc[n] fields, which might be out-of-bounds.

==
BUG: KASAN: slab-out-of-bounds in usbhid_parse+0x9b1/0xa20
Read of size 1 at addr 88006c5f8edf by task kworker/1:2/1261

CPU: 1 PID: 1261 Comm: kworker/1:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 usbhid_parse+0x9b1/0xa20 drivers/hid/usbhid/hid-core.c:1004
 hid_add_device+0x16b/0xb30 drivers/hid/hid-core.c:2944
 usbhid_probe+0xc28/0x1100 drivers/hid/usbhid/hid-core.c:1369
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1261:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc+0x14e/0x310 mm/slub.c:3782
 kmalloc ./include/linux/slab.h:498
 usb_get_configuration+0x372/0x2a60 drivers/usb/core/config.c:848
 usb_enumerate_device drivers/usb/core/hub.c:2290
 usb_new_device+0xaae/0x1020 drivers/usb/core/hub.c:2426
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2927:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 free_rb_tree_fname+0x8a/0xe0 fs/ext4/dir.c:402
 ext4_htree_free_dir_info fs/ext4/dir.c:424
 ext4_release_dir+0x49/0x70 fs/ext4/dir.c:622
 __fput+0x33e/0x800 fs/file_table.c:210
 fput+0x1a/0x20 fs/file_table.c:244
 task_work_run+0x1af/0x280 kernel/task_work.c:112
 tracehook_notify_resume ./include/linux/tracehook.h:191
 exit_to_usermode_loop+0x1e1/0x220 arch/x86/entry/common.c:162
 prepare_exit_to_usermode arch/x86/entry/common.c:197
 syscall_return_slowpath+0x414/0x480 arch/x86/entry/common.c:266
 entry_SYSCALL_64_fastpath+0xc0/0xc2 arch/x86/entry/entry_64.S:238

The buggy address belongs to the object at 88006c5f8ea0
 which belongs to the cache kmalloc-64 of size 64
The buggy address is located 63 bytes inside of
 64-byte region [88006c5f8ea0, 88006c5f8ee0)
The buggy address belongs to the page:
page:ea0001b17e00 count:1 mapcount:0 mapping:  (null) index:0x0
flags: 0x1000100(slab)
raw: 01000100   0001002a002a
raw: ea0001a83000 00150015 88006c403800 
page dumped because: kasan: 

usb/core: slab-out-of-bounds in usb_set_configuration

[Andrey Konovalov]

Hi!

I've got the following crash while fuzzing the kernel with syzkaller.

On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).

It seems there's no proper size check of a
USB_DT_INTERFACE_ASSOCIATION descriptor. It's only checked that the
size is >= 2 in usb_parse_configuration(), so find_iad() might do
out-of-bounds access to intf_assoc->bInterfaceCount.

gadgetfs: bound to dummy_udc driver
usb 1-1: new full-speed USB device number 2 using dummy_hcd
gadgetfs: connected
gadgetfs: disconnected
gadgetfs: connected
usb 1-1: config 1 interface 0 altsetting 0 has an invalid endpoint
with address 0x0, skipping
usb 1-1: New USB device found, idVendor=0020, idProduct=410e
usb 1-1: New USB device strings: Mfr=0, Product=8, SerialNumber=3
usb 1-1: Product: a
usb 1-1: SerialNumber: a
==
BUG: KASAN: slab-out-of-bounds in usb_set_configuration+0x1859/0x1870
Read of size 1 at addr 88006a9d00de by task kworker/0:2/1260

CPU: 0 PID: 1260 Comm: kworker/0:2 Not tainted
4.14.0-rc1-42251-gebb2c2437d80 #169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:16
 dump_stack+0x292/0x395 lib/dump_stack.c:52
 print_address_description+0x78/0x280 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x22f/0x340 mm/kasan/report.c:409
 __asan_report_load1_noabort+0x19/0x20 mm/kasan/report.c:427
 find_iad drivers/usb/core/message.c:1644
 usb_set_configuration+0x1859/0x1870 drivers/usb/core/message.c:1855
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Allocated by task 1260:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
 __kmalloc+0x14e/0x310 mm/slub.c:3782
 kmalloc ./include/linux/slab.h:498
 usb_get_configuration+0x372/0x2a60 drivers/usb/core/config.c:848
 usb_enumerate_device drivers/usb/core/hub.c:2290
 usb_new_device+0xaae/0x1020 drivers/usb/core/hub.c:2426
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

Freed by task 2870:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 load_elf_binary+0x39c2/0x4fa0 fs/binfmt_elf.c:1087
 search_binary_handler+0x146/0x480 fs/exec.c:1634
 exec_binprm fs/exec.c:1676
 do_execveat_common.isra.31+0x16d2/0x2200 fs/exec.c:1798
 do_execve fs/exec.c:1842
 SYSC_execve fs/exec.c:1923
 SyS_execve+0x3e/0x50 fs/exec.c:1918
 do_syscall_64+0x2c5/0x830 arch/x86/entry/common.c:287
 return_from_SYSCALL_64+0x0/0x7a arch/x86/entry/entry_64.S:245

The buggy address belongs to the object at 88006a9d00c0
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 30 bytes inside of
 32-byte region [88006a9d00c0, 88006a9d00e0)
The buggy address belongs to the page:
page:ea0001aa7400 count:1 mapcount:0 mapping:  (null)
index:0x88006a9d05a0
flags: 0x1000100(slab)
raw: 01000100  88006a9d05a0 000180550054
raw: ea000193fa00 00140014 88006c403980 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 88006a9cff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88006a9d: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
>88006a9d0080: fc fc fb fb fb fb fc fc 00 00 00 05 fc fc fb fb
  

Re: Yet another Seagate quirk for unusual_uas.h

[Alan Stern]

On Mon, 18 Sep 2017, Kris Lindgren wrote:

> >> What happens if you plug the disk drive into a regular Linux desktop
> >> computer?  Remember, if an unusual_uas.h entry is added, it will affect
> >> those machines too.
> >
> > I will need to get back to you on this.  All of my other machines
> > running linux, only have usb2.0 hubs.  They are also haven't been used
> > in some time and are running older versions of Ubuntu.
> 
> I upgraded a machine to the latest Ubuntu LTS distro - which is using
> the 4.4 kernel
> 
> When plugging in the drive without any modification, the drive fails to mount.
> Dmesg output:
> [  378.353553] usb 2-1.3: new high-speed USB device number 3 using ehci-pci
> [  378.489981] usb 2-1.3: New USB device found, idVendor=0bc2, idProduct=3332
> [  378.489985] usb 2-1.3: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [  378.489987] usb 2-1.3: Product: External
> [  378.489989] usb 2-1.3: Manufacturer: Seagate
> [  378.489990] usb 2-1.3: SerialNumber: 2GHP5NM9
> [  378.650153] usb-storage 2-1.3:1.0: USB Mass Storage device detected
> [  378.650267] scsi host6: usb-storage 2-1.3:1.0
> [  378.650359] usbcore: registered new interface driver usb-storage
> [  378.684653] usbcore: registered new interface driver uas
> [  379.651163] scsi 6:0:0:0: Direct-Access Seagate  External
>   SG12 PQ: 0 ANSI: 4
> [  379.651892] sd 6:0:0:0: Attached scsi generic sg2 type 0
> [  379.652324] sd 6:0:0:0: [sdb] 3907029164 512-byte logical blocks:
> (2.00 TB/1.82 TiB)
> [  379.653077] sd 6:0:0:0: [sdb] Write Protect is off
> [  379.653081] sd 6:0:0:0: [sdb] Mode Sense: 1c 00 00 00
> [  379.654529] sd 6:0:0:0: [sdb] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [  379.723781]  sdb: sdb1
> [  379.726584] sd 6:0:0:0: [sdb] Attached SCSI disk
> [  379.907727] sd 6:0:0:0: [sdb] tag#0 FAILED Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
> [  379.907737] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error
> [current] [descriptor]
> [  379.907741] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense
> information
> [  379.907747] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass
> through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
> [  380.008600] sd 6:0:0:0: [sdb] tag#0 FAILED Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
> [  380.008608] sd 6:0:0:0: [sdb] tag#0 Sense Key : Hardware Error
> [current] [descriptor]
> [  380.008611] sd 6:0:0:0: [sdb] tag#0 Add. Sense: No additional sense
> information
> [  380.008616] sd 6:0:0:0: [sdb] tag#0 CDB: ATA command pass
> through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00
> [  380.426654] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [  380.426662] sd 6:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current]
> [  380.42] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Invalid field in cdb
> [  380.426670] sd 6:0:0:0: [sdb] tag#0 CDB: Synchronize Cache(10) 35
> 00 00 00 00 00 00 00 00 00
> [  380.426677] blk_update_request: critical target error, dev sdb, sector 0
> [  380.426692] JBD2: recovery failed
> [  380.426698] EXT4-fs (sdb1): error loading journal
> 
> kernel version is:  4.4.0-93-generic

And if you use the w quirk flag?

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 v9] usb: serial: add vid:pid for Cypress WICED dev board

[Jeffrey Chu]

Thanks,  -Jeffrey

-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
Sent: Monday, September 18, 2017 4:41 AM
To: Sheng-Hui J. Chu 
Cc: gre...@linuxfoundation.org; jo...@kernel.org; linux-usb@vger.kernel.org; 
linux-ker...@vger.kernel.org; Jeffrey Chu 
Subject: Re: [PATCH v9] usb: serial: add vid:pid for Cypress WICED dev board

On Fri, Sep 08, 2017 at 09:08:58PM +, Sheng-Hui J. Chu wrote:
> From: Jeffrey Chu 
>
> Add CYPRESS_VID vid and CYPRESS_WICED_BT_USB and CYPRESS_WICED_WL_USB
> device IDs to ftdi_sio driver
>
> Signed-off-by: Jeffrey Chu 

I have two v9 of this patch in my mailbox with different authorship and sent 
five minutes apart. I figured you really wanted this last one applied, but next 
time make sure to increase the patch revision (e.g.
mark it as v10) to avoid any confusion.

> ---
>  drivers/usb/serial/ftdi_sio.c | 2 ++
>  drivers/usb/serial/ftdi_sio_ids.h | 7 +++
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c
> b/drivers/usb/serial/ftdi_sio.c index 1cec037..49d1b2d 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1015,6 +1015,8 @@ static const struct usb_device_id id_table_combined[] = 
> {
>  { USB_DEVICE(WICED_VID, WICED_USB20706V2_PID) },
>  { USB_DEVICE(TI_VID, TI_CC3200_LAUNCHPAD_PID),
>  .driver_info = (kernel_ulong_t)_jtag_quirk },
> +{ USB_DEVICE(CYPRESS_VID, CYPRESS_WICED_BT_USB_PID) },
> +{ USB_DEVICE(CYPRESS_VID, CYPRESS_WICED_WL_USB_PID) },
>  { }/* Terminating entry */
>  };
>
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h
> b/drivers/usb/serial/ftdi_sio_ids.h
> index 4fcf1ce..d58dc1b 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -692,6 +692,13 @@
>  #define WICED_USB20706V2_PID0x6422
>
>  /*
> + * Cypress WICED USB UART
> + */
> +#define CYPRESS_VID0x04B4
> +#define CYPRESS_WICED_BT_USB_PID0x009B
> +#define CYPRESS_WICED_WL_USB_PID0xF900
> +
> +/*
>   * Definitions for ID TECH (www.idt-net.com) devices
>   */
>  #define IDTECH_VID0x0ACD/* ID TECH Vendor ID */

I've applied this one now with some minor tweaks (e.g. kept the define sections 
sorted by VID, and adjusted the commit message slightly).

Thanks,
Johan

This message and any attachments may contain confidential information from 
Cypress or its subsidiaries. If it has been received in error, please advise 
the sender and immediately delete this message.
--
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: Yet another Seagate quirk for unusual_uas.h

[Kris Lindgren]

On Sun, Sep 17, 2017 at 7:02 PM, Kris Lindgren  wrote:
> On Sun, Sep 17, 2017 at 3:41 PM, Alan Stern  wrote:
>> Please use Reply-To-All so that your message gets sent to the mailing
>> and not just to me.
>>
>> Also, please don't top-post.
>>
>> On Sun, 17 Sep 2017, Kris Lindgren wrote:
>>
>>> Sorry, Let me be more specific and answer your questions.
>>>
>>> Without any changes, I plugin the drive, it will fail with sector 0
>>> errors on any action that attempts to write against it.  Such as
>>> formating the volume, creating a folder, touching a file, ect ect.
>>> Unloading usb_storage and reloading it with:
>>> quirks=0bc2:3332:uw causes the drive to function without any issues.
>>> Trying just quirks=0bc2:3332:u or quirks=0bc2:3332:t (as some other
>>> people reported for other seagate explansions drives) still cause
>>> sector 0 errors to show up.
>>
>> What happens with quirks=0bc2:3332:w (leave out the u)?
>> And can you provide the output from lsusb -v for this device?
>
> The drive actually mounts and works fine.  I was able to write 10GB to
> it successfully at an average speed of ~133.9MB/s.
>
> # lsusb -v
>
> Bus 002 Device 011: ID 0bc2:3332 Seagate RSS LLC
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   3.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize0 9
>   idVendor   0x0bc2 Seagate RSS LLC
>   idProduct  0x3332
>   bcdDevice0.12
>   iManufacturer   1 Seagate
>   iProduct2 External
>   iSerial 3 2GHP5NM9
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   44
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xc0
>   Self Powered
> MaxPower   24mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass 8 Mass Storage
>   bInterfaceSubClass  6 SCSI
>   bInterfaceProtocol 80 Bulk (Zip)
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0400  1x 0 bytes
> bInterval   0
> UNRECOGNIZED:  06 30 0f 00 00 00
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0400  1x 0 bytes
> bInterval   0
> UNRECOGNIZED:  06 30 0f 00 00 00
> Device Status: 0x000d
>   Self Powered
>   Test Mode
>
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   3.00
>   bDeviceClass9 Hub
>   bDeviceSubClass 0 Unused
>   bDeviceProtocol 3
>   bMaxPacketSize0 9
>   idVendor   0x1d6b Linux Foundation
>   idProduct  0x0003 3.0 root hub
>   bcdDevice4.02
>   iManufacturer   3 Linux 4.2.8 xhci-hcd
>   iProduct2 xHCI Host Controller
>   iSerial 1 :00:14.0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength   31
> bNumInterfaces  1
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xe0
>   Self Powered
>   Remote Wakeup
> MaxPower0mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   1
>   bInterfaceClass 9 Hub
>   bInterfaceSubClass  0 Unused
>   bInterfaceProtocol  0 Full speed (or root) hub
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize   

Re: how to instrument/debug module loading

[Cliff Brake]

On Mon, Sep 18, 2017 at 11:55 AM, Greg KH  wrote:
> On Mon, Sep 18, 2017 at 11:28:32AM -0400, Cliff Brake wrote:
>> On Thu, Sep 14, 2017 at 12:37 PM, Greg KH  wrote:
>> > On Thu, Sep 14, 2017 at 08:20:09AM -0400, Cliff Brake wrote:
>> >> Hi,
>> >>
>> >> I'm trying to better understand the kernel module loading mechanism
>> >> (for example when you plug in a USB device and a kernel module
>> >> autoloads).  It appears that depmod creates a module.alias map that
>> >> maps USB info to modules.  Is there any way to instrument or observe
>> >> the actual loading process?
>> >
>> > Why do you need to "observe" it?  You can always use kprobes or some
>> > tracing tool to see the filesystem accesses if you really care about
>> > this.
>> >
>> > But it should all "just work", right?  Is something failing for you?
>>
>> Its working great -- more just a point of curiosity -- would like to
>> understand what user-space tool is actually getting called to do the
>> module loading.  Especially since the /sbin/hotplug location/mechanism
>> seems to have changed -- seems we should get some of the documentation
>> updated (unless I'm missing something).  Thanks for the kprobes idea
>> -- will look into that and kernel source ...
>>
>> (BTW, this curiosity was motivated by a Eudyptula Challenge exercise)
>
> Not good, that's against the rules, last time I checked...

Sigh -- this is very demotivating.  I thought a simple dmesg would
good enough "proof" for the Eudyptula Challenge.  The intent here was
NOT to cheat on the Eudyptula Challenge, but to go beyond what I
thought the Eudyptula Challenge required and hopefully fix up some
kernel documentation (Documentation/usb/hotplug.txt) -- perhaps its
all correct and up to date and I'm just missing something ...

I'm not a profilic kernel guy, but I have made several contributions
in the past, and have been helping companies implement various
products using Linux + OpenEmbedded over the past 15 years.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author=Cliff+Brake

So my intent was simply honest discussion.  Sorry this was clear -- I
will go my way and not bother you busy folks any more.

Cliff
--
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: how to instrument/debug module loading

[Greg KH]

On Mon, Sep 18, 2017 at 11:28:32AM -0400, Cliff Brake wrote:
> On Thu, Sep 14, 2017 at 12:37 PM, Greg KH  wrote:
> > On Thu, Sep 14, 2017 at 08:20:09AM -0400, Cliff Brake wrote:
> >> Hi,
> >>
> >> I'm trying to better understand the kernel module loading mechanism
> >> (for example when you plug in a USB device and a kernel module
> >> autoloads).  It appears that depmod creates a module.alias map that
> >> maps USB info to modules.  Is there any way to instrument or observe
> >> the actual loading process?
> >
> > Why do you need to "observe" it?  You can always use kprobes or some
> > tracing tool to see the filesystem accesses if you really care about
> > this.
> >
> > But it should all "just work", right?  Is something failing for you?
> 
> Its working great -- more just a point of curiosity -- would like to
> understand what user-space tool is actually getting called to do the
> module loading.  Especially since the /sbin/hotplug location/mechanism
> seems to have changed -- seems we should get some of the documentation
> updated (unless I'm missing something).  Thanks for the kprobes idea
> -- will look into that and kernel source ...
> 
> (BTW, this curiosity was motivated by a Eudyptula Challenge exercise)

Not good, that's against the rules, last time I checked...
--
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: how to instrument/debug module loading

[Cliff Brake]

On Thu, Sep 14, 2017 at 12:37 PM, Greg KH  wrote:
> On Thu, Sep 14, 2017 at 08:20:09AM -0400, Cliff Brake wrote:
>> Hi,
>>
>> I'm trying to better understand the kernel module loading mechanism
>> (for example when you plug in a USB device and a kernel module
>> autoloads).  It appears that depmod creates a module.alias map that
>> maps USB info to modules.  Is there any way to instrument or observe
>> the actual loading process?
>
> Why do you need to "observe" it?  You can always use kprobes or some
> tracing tool to see the filesystem accesses if you really care about
> this.
>
> But it should all "just work", right?  Is something failing for you?

Its working great -- more just a point of curiosity -- would like to
understand what user-space tool is actually getting called to do the
module loading.  Especially since the /sbin/hotplug location/mechanism
seems to have changed -- seems we should get some of the documentation
updated (unless I'm missing something).  Thanks for the kprobes idea
-- will look into that and kernel source ...

(BTW, this curiosity was motivated by a Eudyptula Challenge exercise)

Thanks,
Cliff

-- 
=
http://bec-systems.com
--
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/8] usb: host: xhci-plat: allow sysdev to inherit from ACPI

[Mathias Nyman]

From: Adam Wallis 

Commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
updated the method determining DMA for XHCI from sysdev. However, this
patch broke the ability to enumerate the FWNODE from parent ACPI devices
from the child plat XHCI device.

Currently, xhci_plat is not set up properly when the parent device is an
ACPI node. The conditions that xhci_plat_probe should satisfy are

1. xhci_plat comes from firmware
2. xhci_plat is child of a device from firmware (dwc3-plat)
3. xhci_plat is grandchild of a pci device (dwc3-pci)

Case 2 is covered when the child is an OF node (by checking
sysdev->parent->of_node), however, an ACPI parent will return NULL in
the of_node check and will thus not result in sysdev being set to
sysdev->parent

[   17.591549] xhci-hcd: probe of xhci-hcd.6.auto failed with error -5

This change adds a check for ACPI to completely allow for condition 2.
This is done by first checking if the parent node is of type ACPI (e.g.,
dwc3-plat) and set sysdev to sysdev->parent if either of the two
following conditions are met:

1: If fwnode is empty (in the case that platform_device_add_properties
was not called on the allocated platform device)
2: fwnode exists but is not of type ACPI (this would happen if
platform_device_add_properties was called on the allocated device.
Instead of type FWNODE_ACPI, you would end up with FWNODE_PDATA)

Cc: sta...@vger.kernel.org #4.12.x
Cc: sta...@vger.kernel.org #4.13.x

Fixes: 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA configuration")
Tested-by: Thang Q. Nguyen 
Signed-off-by: Adam Wallis 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-plat.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 163bafd..1cb6eae 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -178,14 +178,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
 * 2. xhci_plat is child of a device from firmware (dwc3-plat)
 * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
 */
-   sysdev = >dev;
-   if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
-   sysdev = sysdev->parent;
+   for (sysdev = >dev; sysdev; sysdev = sysdev->parent) {
+   if (is_of_node(sysdev->fwnode) ||
+   is_acpi_device_node(sysdev->fwnode))
+   break;
 #ifdef CONFIG_PCI
-   else if (sysdev->parent && sysdev->parent->parent &&
-sysdev->parent->parent->bus == _bus_type)
-   sysdev = sysdev->parent->parent;
+   else if (sysdev->bus == _bus_type)
+   break;
 #endif
+   }
+
+   if (!sysdev)
+   sysdev = >dev;
 
/* Try to set 64-bit DMA first */
if (WARN_ON(!sysdev->dma_mask))
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/8] Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

[Mathias Nyman]

From: Kai-Heng Feng 

This reverts commit dec08194ffeccfa1cf085906b53d301930eae18f.

Commit dec08194ffec ("xhci: Limit USB2 port wake support for AMD Promontory
hosts") makes all high speed USB ports on ASUS PRIME B350M-A cease to
function after enabling runtime PM.

All boards with this chipsets will be affected, so revert the commit.

The original patch was added to stable 4.9, 4.11 and 4.12 and needs
to reverted from there as well

Cc:  # 4.9+
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c |  3 ---
 drivers/usb/host/xhci-pci.c | 12 
 drivers/usb/host/xhci.h |  2 +-
 3 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 4dba2cf..da9158f 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1515,9 +1515,6 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t2 |= PORT_WKOC_E | PORT_WKCONN_E;
t2 &= ~PORT_WKDISC_E;
}
-   if ((xhci->quirks & XHCI_U2_DISABLE_WAKE) &&
-   (hcd->speed < HCD_USB3))
-   t2 &= ~PORT_WAKE_BITS;
} else
t2 &= ~PORT_WAKE_BITS;
 
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 8071c8f..76f3929 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -54,11 +54,6 @@
 #define PCI_DEVICE_ID_INTEL_APL_XHCI   0x5aa8
 #define PCI_DEVICE_ID_INTEL_DNV_XHCI   0x19d0
 
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_40x43b9
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_30x43ba
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_20x43bb
-#define PCI_DEVICE_ID_AMD_PROMONTORYA_10x43bc
-
 #define PCI_DEVICE_ID_ASMEDIA_1042A_XHCI   0x1142
 
 static const char hcd_name[] = "xhci_hcd";
@@ -142,13 +137,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_AMD)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
 
-   if ((pdev->vendor == PCI_VENDOR_ID_AMD) &&
-   ((pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_4) ||
-   (pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_3) ||
-   (pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_2) ||
-   (pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_1)))
-   xhci->quirks |= XHCI_U2_DISABLE_WAKE;
-
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 7c87189..2b48aa4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1828,7 +1828,7 @@ struct xhci_hcd {
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
-#define XHCI_U2_DISABLE_WAKE   (1 << 27)
+/* Reserved. It was XHCI_U2_DISABLE_WAKE */
 #define XHCI_ASMEDIA_MODIFY_FLOWCONTROL(1 << 28)
 
unsigned intnum_active_eps;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/8] xhci: set missing SuperSpeedPlus Link Protocol bit in roothub descriptor

[Mathias Nyman]

A SuperSpeedPlus roothub needs to have the Link Protocol (LP) bit set in
the bmSublinkSpeedAttr[] entry of a SuperSpeedPlus descriptor.

If the xhci controller has an optional Protocol Speed ID (PSI) table then
that will be used as a base to create the roothub SuperSpeedPlus
descriptor.
The PSI table does not however necessary contain the LP bit so we need
to set it manually.

Check the psi speed and set LP bit if speed is 10Gbps or higher.
We're not setting it for 5 to 10Gbps as USB 3.1 specification always
mention SuperSpeedPlus for 10Gbps or higher, and some SSIC USB 3.0 speeds
can be over 5Gbps, such as SSIC-G3B-L1 at 5830 Mbps

Cc:  # 4.6+
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index ad89a6d..4dba2cf 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -112,7 +112,7 @@ static int xhci_create_usb3_bos_desc(struct xhci_hcd *xhci, 
char *buf,
 
/* If PSI table exists, add the custom speed attributes from it */
if (usb3_1 && xhci->usb3_rhub.psi_count) {
-   u32 ssp_cap_base, bm_attrib, psi;
+   u32 ssp_cap_base, bm_attrib, psi, psi_mant, psi_exp;
int offset;
 
ssp_cap_base = USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE;
@@ -139,6 +139,15 @@ static int xhci_create_usb3_bos_desc(struct xhci_hcd 
*xhci, char *buf,
for (i = 0; i < xhci->usb3_rhub.psi_count; i++) {
psi = xhci->usb3_rhub.psi[i];
psi &= ~USB_SSP_SUBLINK_SPEED_RSVD;
+   psi_exp = XHCI_EXT_PORT_PSIE(psi);
+   psi_mant = XHCI_EXT_PORT_PSIM(psi);
+
+   /* Shift to Gbps and set SSP Link BIT(14) if 10Gpbs */
+   for (; psi_exp < 3; psi_exp++)
+   psi_mant /= 1000;
+   if (psi_mant >= 10)
+   psi |= BIT(14);
+
if ((psi & PLT_MASK) == PLT_SYM) {
/* Symmetric, create SSA RX and TX from one PSI entry */
put_unaligned_le32(psi, [offset]);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/8] xhci: Fix sleeping with spin_lock_irq() held in ASmedia 1042A workaround

[Mathias Nyman]

The flow control workaround for ASM1042A xHC hosts sleeps between
register polling. The workaround gets called in several places, among
them with spin_lock_irq() held when xHC host is resumed or hoplug removed.

This was noticed as kernel panics at resume on a Dell XPS15 9550 with
TB16 thunderbolt dock.

Avoid sleeping with spin_lock_irq() held, use udelay() instead

The original workaround was added to 4.9 and 4.12 stable releases,
this patch needs to be applied to those as well.

Fixes: 9da5a1092b13 ("xhci: Bad Ethernet performance plugged in ASM1042A host")
Cc:  #4.9+
Reported-by: Jose Marino 
Tested-by: Jose Marino 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/pci-quirks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index e02dbb1..6dda362 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -447,7 +447,7 @@ static int usb_asmedia_wait_write(struct pci_dev *pdev)
if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
return 0;
 
-   usleep_range(40, 60);
+   udelay(50);
}
 
dev_warn(>dev, "%s: check_write_ready timeout", __func__);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/8] xhci: fix wrong endpoint ESIT value shown in tracing

[Mathias Nyman]

Read the endpiont ESIT from endpiont context using correct macro.
Add a macro for reading the high bits of ESIT for Large ESIT Payload
Capable hosts (LEC=1)

Cc:  # 4.12
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e96e90d..7c87189 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -735,6 +735,8 @@ struct xhci_ep_ctx {
 #define EP_MAXPSTREAMS(p)  (((p) << 10) & EP_MAXPSTREAMS_MASK)
 /* Endpoint is set up with a Linear Stream Array (vs. Secondary Stream Array) 
*/
 #defineEP_HAS_LSA  (1 << 15)
+/* hosts with LEC=1 use bits 31:24 as ESIT high bits. */
+#define CTX_TO_MAX_ESIT_PAYLOAD_HI(p)  (((p) >> 24) & 0xff)
 
 /* ep_info2 bitmasks */
 /*
@@ -2540,8 +2542,8 @@ static inline const char *xhci_decode_ep_context(u32 
info, u32 info2, u64 deq,
u8 lsa;
u8 hid;
 
-   esit = EP_MAX_ESIT_PAYLOAD_HI(info) << 16 |
-   EP_MAX_ESIT_PAYLOAD_LO(tx_info);
+   esit = CTX_TO_MAX_ESIT_PAYLOAD_HI(info) << 16 |
+   CTX_TO_MAX_ESIT_PAYLOAD(tx_info);
 
ep_state = info & EP_STATE_MASK;
max_pstr = info & EP_MAXPSTREAMS_MASK;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/8] usb: pci-quirks.c: Corrected timeout values used in handshake

[Mathias Nyman]

From: Jim Dickerson 

Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds not 1 second as
in specs.

The wrong units were also corrected in a second handshake call.

Cc: 
Signed-off-by: Jim Dickerson 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/pci-quirks.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 658d9d1..e02dbb1 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1022,7 +1022,7 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
  *
  * Takes care of the handoff between the Pre-OS (i.e. BIOS) and the OS.
  * It signals to the BIOS that the OS wants control of the host controller,
- * and then waits 5 seconds for the BIOS to hand over control.
+ * and then waits 1 second for the BIOS to hand over control.
  * If we timeout, assume the BIOS is broken and take control anyway.
  */
 static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
@@ -1069,9 +1069,9 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
if (val & XHCI_HC_BIOS_OWNED) {
writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
 
-   /* Wait for 5 seconds with 10 microsecond polling interval */
+   /* Wait for 1 second with 10 microsecond polling interval */
timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
-   0, 5000, 10);
+   0, 100, 10);
 
/* Assume a buggy BIOS and take HC ownership anyway */
if (timeout) {
@@ -1100,7 +1100,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
 * operational or runtime registers.  Wait 5 seconds and no more.
 */
timeout = handshake(op_reg_base + XHCI_STS_OFFSET, XHCI_STS_CNR, 0,
-   5000, 10);
+   500, 10);
/* Assume a buggy HC and start HC initialization anyway */
if (timeout) {
val = readl(op_reg_base + XHCI_STS_OFFSET);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] xhci fixes for usb-linus

[Mathias Nyman]

Hi Greg

Some small but important xhci fixes for usb-linus.
A few vendor specific fixes, some USB 3.1 related issues
related to resume and showing correct 10Gbps speed and
other small fixes

-Mathias

Adam Wallis (1):
  usb: host: xhci-plat: allow sysdev to inherit from ACPI

Jim Dickerson (1):
  usb: pci-quirks.c: Corrected timeout values used in handshake

Kai-Heng Feng (1):
  Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

Lu Baolu (1):
  usb: xhci: Free the right ring in xhci_add_endpoint()

Mathias Nyman (4):
  xhci: fix finding correct bus_state structure for USB 3.1 hosts
  xhci: fix wrong endpoint ESIT value shown in tracing
  xhci: Fix sleeping with spin_lock_irq() held in ASmedia 1042A
workaround
  xhci: set missing SuperSpeedPlus Link Protocol bit in roothub
descriptor

 drivers/usb/host/pci-quirks.c | 10 +-
 drivers/usb/host/xhci-hub.c   | 14 ++
 drivers/usb/host/xhci-pci.c   | 12 
 drivers/usb/host/xhci-plat.c  | 16 ++--
 drivers/usb/host/xhci.c   |  3 ++-
 drivers/usb/host/xhci.h   | 10 ++
 6 files changed, 33 insertions(+), 32 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/8] usb: xhci: Free the right ring in xhci_add_endpoint()

[Mathias Nyman]

From: Lu Baolu 

In the xhci_add_endpoint(), a new ring was allocated and saved at
xhci_virt_ep->new_ring. Hence, when error happens, we need to free
the allocated ring before returning error.

Current code frees xhci_virt_ep->ring instead of the new_ring. This
patch fixes this.

Cc: 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b2ff1ff..ee198ea 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1703,7 +1703,8 @@ static int xhci_add_endpoint(struct usb_hcd *hcd, struct 
usb_device *udev,
if (xhci->quirks & XHCI_MTK_HOST) {
ret = xhci_mtk_add_ep_quirk(hcd, udev, ep);
if (ret < 0) {
-   xhci_free_endpoint_ring(xhci, virt_dev, ep_index);
+   xhci_ring_free(xhci, virt_dev->eps[ep_index].new_ring);
+   virt_dev->eps[ep_index].new_ring = NULL;
return ret;
}
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/8] xhci: fix finding correct bus_state structure for USB 3.1 hosts

[Mathias Nyman]

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared
for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

Cc: 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 2abaa4d..e96e90d 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1681,7 +1681,7 @@ struct xhci_bus_state {
 
 static inline unsigned int hcd_index(struct usb_hcd *hcd)
 {
-   if (hcd->speed == HCD_USB3)
+   if (hcd->speed >= HCD_USB3)
return 0;
else
return 1;
-- 
1.9.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: Gadget mode advice sought

[g4]

Hi and thanks

> 3.4??? sorry, you're on your own. You need to ask for support from whoever
forces you to stay on this kernel.

Absolutely but sadly it is the all-important camera interface which is
completely missing from mainline. 

That said I have GadgetFS working to the extent it is showing up as a nearly
functional bulk-mode device.

BR.

--
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] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Andrzej Pietrasiewicz]

Hi,

W dniu 18.09.2017 o 14:43, Felipe Balbi pisze:


Hi,

Andrzej Pietrasiewicz  writes:

+static int exynos5_usbdrd_phy_reset(struct phy *phy)
+{
+   struct phy_usb_instance *inst = phy_get_drvdata(phy);
+   struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+   return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
static const struct phy_ops exynos5_usbdrd_phy_ops = {
.init   = exynos5_usbdrd_phy_init,
.exit   = exynos5_usbdrd_phy_exit,
.power_on   = exynos5_usbdrd_phy_power_on,
.power_off  = exynos5_usbdrd_phy_power_off,
+   .reset  = exynos5_usbdrd_phy_reset,
.owner  = THIS_MODULE,
};

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c

index 03474d3..1d5836e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
} else {
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, true);
-   if (dwc->usb2_generic_phy)
+   if (dwc->usb2_generic_phy) {
phy_set_mode(dwc->usb2_generic_phy, 
PHY_MODE_USB_HOST);
-
+   phy_reset(dwc->usb2_generic_phy);


it doesn't look like this is the best place to reset the phy. Also,


right, phy_reset is done during initialization before phy_power_on/phy_init or
in error cases.


->reset() doesn't seem to match correctly with a calibration. That seems
to be more fitting to a ->power_on() or ->init() implementation.


yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's
modified.


The original patch used a hack like below, in xhci_plat_probe():

+   /* Initialize and power-on USB 3.0 PHY */
+   xhci->shared_hcd->phy->init_count = 0;
+   ret = phy_init(xhci->shared_hcd->phy);
+   if (ret)
+   goto dealloc_usb3_hcd;
+
+   xhci->shared_hcd->phy->power_count = 0;
+   ret = phy_power_on(xhci->shared_hcd->phy);
+   if (ret) {
+   phy_exit(xhci->shared_hcd->phy);
+   goto dealloc_usb3_hcd;
+   }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to
happen probably does not look good.

The calibration is clearly needed. However, I don't have any strong opinions
on from which place exactly to trigger the calibration process.
The original patch did not make it upstream, but if that patch is ok,
it is perfectly fine with me to drop my version and take that one instead.


Me bad, I did not write about an important issue.
The calibration must happen after usb_add_hcd(), otherwise
usb_add_hcd() indirectly triggers overwriting the effects of calibration.


in that case, you should do that from xhci-plat indeed. I think the
whole idea with init_count is just to make sure you don't initialize it
twice.


As far as I understand the code in question the desired result is exactly the 
opposite:
to make sure it _does_ initialize twice, otherwise after the first 
initialization the
calibration results were lost. In other words, in the code snippet above,
in xhci_plat_probe() the phy_init() was creatively (ab)used in order to force
the calibration at a desired moment, while in the original invocation of 
phy_init()
the calibration result was merely a short-term side effect discarded soon 
afterwards.



One thing's for sure, ->reset() doesn't seem to be the matching callback
for you to use and, given your explanation above, dwc3 doesn't seem to
be the right place to fiddle with that.

Seems like we need an extension of the generic PHY framework to cope
with your requirement.



Here are old patches from Vivek:

https://lkml.org/lkml/2014/9/2/166

In particular:

https://lkml.org/lkml/2014/9/2/170

Please see the discussion that follows the latter.

All in all, is adding the calibrate() method to phy_ops the way to go or not?

Andrzej
--
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: [regression] Force hard reset of Renesas uPD72020x USB controller

[Albert Weichselbraun]

On Mon, 2017-09-18 at 12:46 +0100, Marc Zyngier wrote:
> On 18/09/17 09:49, Albert Weichselbraun wrote:
> > Hi Marc,
> > 
> > 100% ack
> > - Booting with a kernel that does not do a PCI reset yields the
> >   following topology:
> > 
> > 
> > -[:00] -
> >  +-00.0  Intel Corporation 2nd Generation Core Processor Family
> > DRAM
> >  Controller
> >  +-02.0  Intel Corporation 2nd Generation Core Processor Family
> >  Integrated Graphics Controller
> >  +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI
> >  Controller #1
> >  +-19.0  Intel Corporation 82579LM Gigabit Network Connection
> >  +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
> >  Enhanced Host Controller #2
> >  +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High
> >  Definition Audio Controller
> >  +-1c.0-[02]--
> >  +-1c.1-[03]00.0  Intel Corporation Centrino Advanced-N 6205
> >   [Taylor Peak]
> >  +-1c.3-[05-0c]00.0  Renesas Technology Corp. uPD720202 USB 3.0
> >  Host Controller
> >  +-1c.4-[0d]00.0  Ricoh Co Ltd MMC/SD Host Controller
> >  +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
> >  Enhanced Host Controller #1
> >  +-1f.0  Intel Corporation QM67 Express Chipset Family LPC
> > Controller
> >  +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6
> > port
> >  SATA AHCI Controller
> >  \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family
> > SMBus
> >  Controller
> > 
> > 
> > Unplugging and replugging the card (regardless of the kernel
> > version)
> > or booting with a kernel that does the reset leads to the card not
> > being correctly recognized and the problems I have observed.
> 
> Hmmm. Just to make sure I understand you correctly:
> 
> With a non-reset kernel: if you boot *without* the card inserted, but
> insert it at a later time, the card is unusable? If that's the case,
> that's quite unexpected too...

This is exactly what is happening when booting with a non-reset kernel.
If you insert the card at a later time it is unusable and the system
starts to behave sluggish. 
There is also not a single line logged in /var/log/kern.log.

Once the card is removed everything is back to normal.

cheers,
  albert:)  



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Felipe Balbi]

Hi,

Andrzej Pietrasiewicz  writes:
> +static int exynos5_usbdrd_phy_reset(struct phy *phy)
> +{
> + struct phy_usb_instance *inst = phy_get_drvdata(phy);
> + struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
> +
> + return exynos5420_usbdrd_phy_calibrate(phy_drd);
> +}
> +
>static const struct phy_ops exynos5_usbdrd_phy_ops = {
>   .init   = exynos5_usbdrd_phy_init,
>   .exit   = exynos5_usbdrd_phy_exit,
>   .power_on   = exynos5_usbdrd_phy_power_on,
>   .power_off  = exynos5_usbdrd_phy_power_off,
> + .reset  = exynos5_usbdrd_phy_reset,
>   .owner  = THIS_MODULE,
>};
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 03474d3..1d5836e 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
>   } else {
>   if (dwc->usb2_phy)
>   otg_set_vbus(dwc->usb2_phy->otg, true);
> - if (dwc->usb2_generic_phy)
> + if (dwc->usb2_generic_phy) {
>   phy_set_mode(dwc->usb2_generic_phy, 
> PHY_MODE_USB_HOST);
> -
> + phy_reset(dwc->usb2_generic_phy);

 it doesn't look like this is the best place to reset the phy. Also,
>>>
>>> right, phy_reset is done during initialization before phy_power_on/phy_init 
>>> or
>>> in error cases.
>>>
 ->reset() doesn't seem to match correctly with a calibration. That seems
 to be more fitting to a ->power_on() or ->init() implementation.
>>>
>>> yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's
>>> modified.
>> 
>> The original patch used a hack like below, in xhci_plat_probe():
>> 
>> +   /* Initialize and power-on USB 3.0 PHY */
>> +   xhci->shared_hcd->phy->init_count = 0;
>> +   ret = phy_init(xhci->shared_hcd->phy);
>> +   if (ret)
>> +   goto dealloc_usb3_hcd;
>> +
>> +   xhci->shared_hcd->phy->power_count = 0;
>> +   ret = phy_power_on(xhci->shared_hcd->phy);
>> +   if (ret) {
>> +   phy_exit(xhci->shared_hcd->phy);
>> +   goto dealloc_usb3_hcd;
>> +   }
>> +
>> 
>> Manually setting init_count to 0 in order for the subsequent phy_init() to
>> happen probably does not look good.
>> 
>> The calibration is clearly needed. However, I don't have any strong opinions
>> on from which place exactly to trigger the calibration process.
>> The original patch did not make it upstream, but if that patch is ok,
>> it is perfectly fine with me to drop my version and take that one instead.
>
> Me bad, I did not write about an important issue.
> The calibration must happen after usb_add_hcd(), otherwise
> usb_add_hcd() indirectly triggers overwriting the effects of calibration.

in that case, you should do that from xhci-plat indeed. I think the
whole idea with init_count is just to make sure you don't initialize it
twice.

One thing's for sure, ->reset() doesn't seem to be the matching callback
for you to use and, given your explanation above, dwc3 doesn't seem to
be the right place to fiddle with that.

Seems like we need an extension of the generic PHY framework to cope
with your requirement.

-- 
balbi


signature.asc
Description: PGP signature

Re: [regression] Force hard reset of Renesas uPD72020x USB controller

[Marc Zyngier]

On 18/09/17 09:49, Albert Weichselbraun wrote:
> Hi Marc,
> 
> 100% ack
> - Booting with a kernel that does not do a PCI reset yields the
>   following topology:
> 
> 
> -[:00] -
>  +-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM
>  Controller
>  +-02.0  Intel Corporation 2nd Generation Core Processor Family
>  Integrated Graphics Controller
>  +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI
>  Controller #1
>  +-19.0  Intel Corporation 82579LM Gigabit Network Connection
>  +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
>  Enhanced Host Controller #2
>  +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High
>  Definition Audio Controller
>  +-1c.0-[02]--
>  +-1c.1-[03]00.0  Intel Corporation Centrino Advanced-N 6205
>   [Taylor Peak]
>  +-1c.3-[05-0c]00.0  Renesas Technology Corp. uPD720202 USB 3.0
>  Host Controller
>  +-1c.4-[0d]00.0  Ricoh Co Ltd MMC/SD Host Controller
>  +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
>  Enhanced Host Controller #1
>  +-1f.0  Intel Corporation QM67 Express Chipset Family LPC Controller
>  +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6 port
>  SATA AHCI Controller
>  \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family SMBus
>  Controller
> 
> 
> Unplugging and replugging the card (regardless of the kernel version)
> or booting with a kernel that does the reset leads to the card not
> being correctly recognized and the problems I have observed.

Hmmm. Just to make sure I understand you correctly:

With a non-reset kernel: if you boot *without* the card inserted, but
insert it at a later time, the card is unusable? If that's the case,
that's quite unexpected too...

M.
-- 
Jazz is not dead. It just smells funny...
--
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] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Andrzej Pietrasiewicz]

Hi,

W dniu 18.09.2017 o 13:27, Andrzej Pietrasiewicz pisze:

W dniu 18.09.2017 o 13:06, Kishon Vijay Abraham I pisze:

Hi,

On Monday 18 September 2017 04:08 PM, Felipe Balbi wrote:


Hi,

Andrzej Pietrasiewicz  writes:

From: Vivek Gautam 

Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.




   
+static int exynos5_usbdrd_phy_reset(struct phy *phy)

+{
+   struct phy_usb_instance *inst = phy_get_drvdata(phy);
+   struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+   return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
   static const struct phy_ops exynos5_usbdrd_phy_ops = {
.init   = exynos5_usbdrd_phy_init,
.exit   = exynos5_usbdrd_phy_exit,
.power_on   = exynos5_usbdrd_phy_power_on,
.power_off  = exynos5_usbdrd_phy_power_off,
+   .reset  = exynos5_usbdrd_phy_reset,
.owner  = THIS_MODULE,
   };
   
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c

index 03474d3..1d5836e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
} else {
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, true);
-   if (dwc->usb2_generic_phy)
+   if (dwc->usb2_generic_phy) {
phy_set_mode(dwc->usb2_generic_phy, 
PHY_MODE_USB_HOST);
-
+   phy_reset(dwc->usb2_generic_phy);


it doesn't look like this is the best place to reset the phy. Also,


right, phy_reset is done during initialization before phy_power_on/phy_init or
in error cases.


->reset() doesn't seem to match correctly with a calibration. That seems
to be more fitting to a ->power_on() or ->init() implementation.


yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's
modified.


The original patch used a hack like below, in xhci_plat_probe():

+   /* Initialize and power-on USB 3.0 PHY */
+   xhci->shared_hcd->phy->init_count = 0;
+   ret = phy_init(xhci->shared_hcd->phy);
+   if (ret)
+   goto dealloc_usb3_hcd;
+
+   xhci->shared_hcd->phy->power_count = 0;
+   ret = phy_power_on(xhci->shared_hcd->phy);
+   if (ret) {
+   phy_exit(xhci->shared_hcd->phy);
+   goto dealloc_usb3_hcd;
+   }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to
happen probably does not look good.

The calibration is clearly needed. However, I don't have any strong opinions
on from which place exactly to trigger the calibration process.
The original patch did not make it upstream, but if that patch is ok,
it is perfectly fine with me to drop my version and take that one instead.


Me bad, I did not write about an important issue.
The calibration must happen after usb_add_hcd(), otherwise
usb_add_hcd() indirectly triggers overwriting the effects of calibration.

Andrzej

--
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] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Andrzej Pietrasiewicz]

W dniu 18.09.2017 o 13:06, Kishon Vijay Abraham I pisze:

Hi,

On Monday 18 September 2017 04:08 PM, Felipe Balbi wrote:


Hi,

Andrzej Pietrasiewicz  writes:

From: Vivek Gautam 

Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.




  
+static int exynos5_usbdrd_phy_reset(struct phy *phy)

+{
+   struct phy_usb_instance *inst = phy_get_drvdata(phy);
+   struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
+
+   return exynos5420_usbdrd_phy_calibrate(phy_drd);
+}
+
  static const struct phy_ops exynos5_usbdrd_phy_ops = {
.init   = exynos5_usbdrd_phy_init,
.exit   = exynos5_usbdrd_phy_exit,
.power_on   = exynos5_usbdrd_phy_power_on,
.power_off  = exynos5_usbdrd_phy_power_off,
+   .reset  = exynos5_usbdrd_phy_reset,
.owner  = THIS_MODULE,
  };
  
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c

index 03474d3..1d5836e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -156,9 +156,10 @@ static void __dwc3_set_mode(struct work_struct *work)
} else {
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, true);
-   if (dwc->usb2_generic_phy)
+   if (dwc->usb2_generic_phy) {
phy_set_mode(dwc->usb2_generic_phy, 
PHY_MODE_USB_HOST);
-
+   phy_reset(dwc->usb2_generic_phy);


it doesn't look like this is the best place to reset the phy. Also,


right, phy_reset is done during initialization before phy_power_on/phy_init or
in error cases.


->reset() doesn't seem to match correctly with a calibration. That seems
to be more fitting to a ->power_on() or ->init() implementation.


yeah, the initial patch seems to calibrate in phy_init(). Not sure why it's
modified.


The original patch used a hack like below, in xhci_plat_probe():

+   /* Initialize and power-on USB 3.0 PHY */
+   xhci->shared_hcd->phy->init_count = 0;
+   ret = phy_init(xhci->shared_hcd->phy);
+   if (ret)
+   goto dealloc_usb3_hcd;
+
+   xhci->shared_hcd->phy->power_count = 0;
+   ret = phy_power_on(xhci->shared_hcd->phy);
+   if (ret) {
+   phy_exit(xhci->shared_hcd->phy);
+   goto dealloc_usb3_hcd;
+   }
+

Manually setting init_count to 0 in order for the subsequent phy_init() to
happen probably does not look good.

The calibration is clearly needed. However, I don't have any strong opinions
on from which place exactly to trigger the calibration process.
The original patch did not make it upstream, but if that patch is ok,
it is perfectly fine with me to drop my version and take that one instead.

Andrzej
--
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/2] dwc3 on XU3 and XU4

[Anand Moon]

Hi Andrzej,

On 18 September 2017 at 15:32, Andrzej Pietrasiewicz
 wrote:
> Hi all,
>
> this short series addresses two issues.
>
> The first issue is devices not enumerating when connected to an Odroid XU4,
> to its 3.0 root hub. The interplay between refactoring certain parts of
> dwc3's code and handling the SUSPHY quirk results in the said problem.
> Please see: https://patchwork.kernel.org/patch/9535235/
> Actually using the quirk solves it.
>
> The second issue is devices not enumerating and/or wrongly enumerating
> as high speed instead of super speed on an Odroid XU3. There was a patch
> series from Vivek Gautam in circulation, but it got lost somehow.
> Please see:
>
> https://lkml.org/lkml/2014/9/2/166
> https://lkml.org/lkml/2015/2/2/257
>
> I adapted his patch so that it does not use a hacky solution to force
> additional initialization in order for calibration to happen.
> Instead I used the .reset() in phy_ops. I could have used the .set_mode(),
> but the calibration must happen only after dwc3_host_init() but
> phy_set_mode() is called either after of before it. With this patch
> enumeration happens correctly and a super speed device is recognized as such.
>
> Rebased onto v4.13. It also applies cleanly to Felipe's testing/next.
>
> Andrzej Pietrasiewicz (1):
>   ARM: dts: exynos: Add dwc3 SUSPHY quirk
>
> Vivek Gautam (1):
>   phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
>
>  arch/arm/boot/dts/exynos54xx.dtsi|   2 +
>  drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 
> +++
>  drivers/usb/dwc3/core.c  |   8 +-
>  3 files changed, 191 insertions(+), 2 deletions(-)
>

Thanks for rending this patch series.

I would like to suggestion some more pointer to this issue.
Both the usb 2.0 phy and usb 3.0 tune and calibrate are missing in the
current driver.
Lately I have searched on this topic on github so accidentally landed on.

[0] 
https://github.com/wanam/Adam-Kernel-GalaxyS6-G920F/blob/master/drivers/usb/phy/phy-samsung-usb3-cal.c
[1] 
https://github.com/wanam/Adam-Kernel-GalaxyS6-G920F/blob/master/drivers/usb/phy/phy-samsung-usb2-cal.c

I have tried to mapped few of the change and was able to partially
stabilize the driver.

But few of the changes are mixed with other platform soc probably Exynos 5433.

Would it be possible for you to look into into this new approach to
fix and stabilize this driver.

Best Regards
-Anand Moon
--
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] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Kishon Vijay Abraham I]

Hi,

On Monday 18 September 2017 04:08 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Andrzej Pietrasiewicz  writes:
>> From: Vivek Gautam 
>>
>> Adding phy calibration sequence for USB 3.0 DRD PHY present on
>> Exynos5420/5800 systems.
>> This calibration facilitates setting certain PHY parameters viz.
>> the Loss-of-Signal (LOS) Detector Threshold Level, as well as
>> Tx-Vboost-Level for Super-Speed operations.
>> Additionally we also set proper time to wait for RxDetect measurement,
>> for desired PHY reference clock, so as to solve issue with enumeration
>> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
>> on the controller.
>>
>> We are using CR_port for this purpose to send required data
>> to override the LOS values.
>>
>> On testing with USB 3.0 devices on USB 3.0 port present on
>> SMDK5420, and peach-pit boards should see following message:
>> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>>
>> and without this patch, should see below shown message:
>> usb 1-1: new high-speed USB device number 2 using xhci-hcd
>>
>> [Also removed unnecessary extra lines in the register macro definitions]
>>
>> Signed-off-by: Vivek Gautam 
>> [adapted to use phy_reset as entry point]
>> Signed-off-by: Andrzej Pietrasiewicz 
>> ---
>>  drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 
>> +++
>>  drivers/usb/dwc3/core.c  |   8 +-
>>  2 files changed, 189 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
>> b/drivers/phy/samsung/phy-exynos5-usbdrd.c
>> index 7c41daa..f7de067 100644
>> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
>> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
>> @@ -89,7 +89,17 @@
>>  #define PHYCLKRST_COMMONONN BIT(0)
>>  
>>  #define EXYNOS5_DRD_PHYREG0 0x14
>> +#define PHYREG0_SSC_REF_CLK_SEL BIT(21)
>> +#define PHYREG0_SSC_RANGE   BIT(20)
>> +#define PHYREG0_CR_WRITEBIT(19)
>> +#define PHYREG0_CR_READ BIT(18)
>> +#define PHYREG0_CR_DATA_IN(_x)  ((_x) << 2)
>> +#define PHYREG0_CR_CAP_DATA BIT(1)
>> +#define PHYREG0_CR_CAP_ADDR BIT(0)
>> +
>>  #define EXYNOS5_DRD_PHYREG1 0x18
>> +#define PHYREG1_CR_DATA_OUT(_x) ((_x) << 1)
>> +#define PHYREG1_CR_ACK  BIT(0)
>>  
>>  #define EXYNOS5_DRD_PHYPARAM0   0x1c
>>  
>> @@ -118,6 +128,25 @@
>>  #define EXYNOS5_DRD_PHYRESUME   0x34
>>  #define EXYNOS5_DRD_LINKPORT0x44
>>  
>> +/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
>> +#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN  (0x15)
>> +#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420  (0x5 << 13)
>> +#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT   (0x0 << 13)
>> +#define LOSLEVEL_OVRD_IN_EN (0x1 << 10)
>> +#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT  (0x9 << 0)
>> +
>> +#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN(0x12)
>> +#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420  (0x5 << 13)
>> +#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT   (0x4 << 13)
>> +
>> +#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG(0x1010)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M (0x4 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M  (0x8 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M  (0x8 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M  (0x20 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5 (0x20 << 4)
>> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M (0x40 << 4)
>> +
>>  #define KHZ 1000
>>  #define MHZ (KHZ * KHZ)
>>  
>> @@ -526,6 +555,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy 
>> *phy)
>>  return 0;
>>  }
>>  
>> +static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
>> +u32 val, u32 cmd)
>> +{
>> +u32 usec = 100;
>> +unsigned int result;
>> +
>> +writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
>> +
>> +do {
>> +result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
>> +if (result & PHYREG1_CR_ACK)
>> +break;
>> +
>> +udelay(1);
>> +} while (usec-- > 0);
>> +
>> +if (!usec) {
>> +dev_err(phy_drd->dev,
>> +"CRPORT handshake timeout1 (0x%08x)\n", val);
>> +return -ETIME;
>> +}
>> +
>> +usec = 100;
>> +
>> +writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
>> +
>> +do {
>> +result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
>> +if (!(result & PHYREG1_CR_ACK))
>> +break;
>> +
>> +

Re: [PATCH 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Felipe Balbi]

Hi,

Andrzej Pietrasiewicz  writes:
> From: Vivek Gautam 
>
> Adding phy calibration sequence for USB 3.0 DRD PHY present on
> Exynos5420/5800 systems.
> This calibration facilitates setting certain PHY parameters viz.
> the Loss-of-Signal (LOS) Detector Threshold Level, as well as
> Tx-Vboost-Level for Super-Speed operations.
> Additionally we also set proper time to wait for RxDetect measurement,
> for desired PHY reference clock, so as to solve issue with enumeration
> of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
> on the controller.
>
> We are using CR_port for this purpose to send required data
> to override the LOS values.
>
> On testing with USB 3.0 devices on USB 3.0 port present on
> SMDK5420, and peach-pit boards should see following message:
> usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd
>
> and without this patch, should see below shown message:
> usb 1-1: new high-speed USB device number 2 using xhci-hcd
>
> [Also removed unnecessary extra lines in the register macro definitions]
>
> Signed-off-by: Vivek Gautam 
> [adapted to use phy_reset as entry point]
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 
> +++
>  drivers/usb/dwc3/core.c  |   8 +-
>  2 files changed, 189 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
> b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> index 7c41daa..f7de067 100644
> --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> @@ -89,7 +89,17 @@
>  #define PHYCLKRST_COMMONONN  BIT(0)
>  
>  #define EXYNOS5_DRD_PHYREG0  0x14
> +#define PHYREG0_SSC_REF_CLK_SEL  BIT(21)
> +#define PHYREG0_SSC_RANGEBIT(20)
> +#define PHYREG0_CR_WRITE BIT(19)
> +#define PHYREG0_CR_READ  BIT(18)
> +#define PHYREG0_CR_DATA_IN(_x)   ((_x) << 2)
> +#define PHYREG0_CR_CAP_DATA  BIT(1)
> +#define PHYREG0_CR_CAP_ADDR  BIT(0)
> +
>  #define EXYNOS5_DRD_PHYREG1  0x18
> +#define PHYREG1_CR_DATA_OUT(_x)  ((_x) << 1)
> +#define PHYREG1_CR_ACK   BIT(0)
>  
>  #define EXYNOS5_DRD_PHYPARAM00x1c
>  
> @@ -118,6 +128,25 @@
>  #define EXYNOS5_DRD_PHYRESUME0x34
>  #define EXYNOS5_DRD_LINKPORT 0x44
>  
> +/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
> +#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN   (0x15)
> +#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420   (0x5 << 13)
> +#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT(0x0 << 13)
> +#define LOSLEVEL_OVRD_IN_EN  (0x1 << 10)
> +#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT   (0x9 << 0)
> +
> +#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN (0x12)
> +#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420   (0x5 << 13)
> +#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT(0x4 << 13)
> +
> +#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG (0x1010)
> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M  (0x4 << 4)
> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M   (0x8 << 4)
> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M   (0x8 << 4)
> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M   (0x20 << 4)
> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5  (0x20 << 4)
> +#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M  (0x40 << 4)
> +
>  #define KHZ  1000
>  #define MHZ  (KHZ * KHZ)
>  
> @@ -526,6 +555,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
>   return 0;
>  }
>  
> +static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
> + u32 val, u32 cmd)
> +{
> + u32 usec = 100;
> + unsigned int result;
> +
> + writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> +
> + do {
> + result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> + if (result & PHYREG1_CR_ACK)
> + break;
> +
> + udelay(1);
> + } while (usec-- > 0);
> +
> + if (!usec) {
> + dev_err(phy_drd->dev,
> + "CRPORT handshake timeout1 (0x%08x)\n", val);
> + return -ETIME;
> + }
> +
> + usec = 100;
> +
> + writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
> +
> + do {
> + result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
> + if (!(result & PHYREG1_CR_ACK))
> + break;
> +
> + udelay(1);
> + } while (usec-- > 0);
> +
> + if (!usec) {
> + dev_err(phy_drd->dev,
> + "CRPORT 

[PATCH 3/4] usb: dwc3: gadget: cache frame number in struct dwc3_ep

[Felipe Balbi]

This is in preparation to simplifying prototype of
__dwc3_gadget_kick_transfer().

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h   | 2 ++
 drivers/usb/dwc3/gadget.c | 7 ++-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index ea910acb4bb0..e33cc10121be 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -529,6 +529,7 @@ struct dwc3_event_buffer {
  * @number: endpoint number (1 - 15)
  * @type: set to bmAttributes & USB_ENDPOINT_XFERTYPE_MASK
  * @resource_index: Resource transfer index
+ * @frame_number: set to the frame number we want this transfer to start (ISOC)
  * @interval: the interval on which the ISOC transfer is started
  * @allocated_requests: number of requests allocated
  * @queued_requests: number of requests queued for transfer
@@ -581,6 +582,7 @@ struct dwc3_ep {
u8  resource_index;
u32 allocated_requests;
u32 queued_requests;
+   u32 frame_number;
u32 interval;
 
charname[20];
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 850fda013768..2c0b9d0e2b05 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1258,8 +1258,6 @@ static int __dwc3_gadget_get_frame(struct dwc3 *dwc)
 static void __dwc3_gadget_start_isoc(struct dwc3 *dwc,
struct dwc3_ep *dep, u32 cur_uf)
 {
-   u32 uf;
-
if (list_empty(>pending_list)) {
dev_info(dwc->dev, "%s: ran out of requests\n",
dep->name);
@@ -1271,9 +1269,8 @@ static void __dwc3_gadget_start_isoc(struct dwc3 *dwc,
 * Schedule the first trb for one interval in the future or at
 * least 4 microframes.
 */
-   uf = cur_uf + max_t(u32, 4, dep->interval);
-
-   __dwc3_gadget_kick_transfer(dep, uf);
+   dep->frame_number = cur_uf + max_t(u32, 4, dep->interval);
+   __dwc3_gadget_kick_transfer(dep, dep->frame_number);
 }
 
 static void dwc3_gadget_start_isoc(struct dwc3 *dwc,
-- 
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

[PATCH 4/4] usb: dwc3: gadget: simplify __dwc3_gadget_kick_transfer() prototype

[Felipe Balbi]

Now that all the information we need sits in struct dwc3_ep, we can
start taking only a pointer to struct dwc3_ep as an argument. This
allows us to clean the code up a bit.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 34 +-
 1 file changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2c0b9d0e2b05..66dc99b9525a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1191,7 +1191,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
}
 }
 
-static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep, u16 cmd_param)
+static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep)
 {
struct dwc3_gadget_ep_cmd_params params;
struct dwc3_request *req;
@@ -1216,8 +1216,10 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep 
*dep, u16 cmd_param)
if (starting) {
params.param0 = upper_32_bits(req->trb_dma);
params.param1 = lower_32_bits(req->trb_dma);
-   cmd = DWC3_DEPCMD_STARTTRANSFER |
-   DWC3_DEPCMD_PARAM(cmd_param);
+   cmd = DWC3_DEPCMD_STARTTRANSFER;
+
+   if (usb_endpoint_xfer_isoc(dep->endpoint.desc))
+   cmd |= DWC3_DEPCMD_PARAM(dep->frame_number);
} else {
cmd = DWC3_DEPCMD_UPDATETRANSFER |
DWC3_DEPCMD_PARAM(dep->resource_index);
@@ -1270,7 +1272,7 @@ static void __dwc3_gadget_start_isoc(struct dwc3 *dwc,
 * least 4 microframes.
 */
dep->frame_number = cur_uf + max_t(u32, 4, dep->interval);
-   __dwc3_gadget_kick_transfer(dep, dep->frame_number);
+   __dwc3_gadget_kick_transfer(dep);
 }
 
 static void dwc3_gadget_start_isoc(struct dwc3 *dwc,
@@ -1340,7 +1342,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
}
 
 out:
-   return __dwc3_gadget_kick_transfer(dep, 0);
+   return __dwc3_gadget_kick_transfer(dep);
 }
 
 static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
@@ -2333,7 +2335,7 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, 
struct dwc3_ep *dep,
req->request.actual = length - req->remaining;
 
if ((req->request.actual < length) && req->num_pending_sgs)
-   return __dwc3_gadget_kick_transfer(dep, 0);
+   return __dwc3_gadget_kick_transfer(dep);
 
dwc3_gadget_giveback(dep, req, status);
 
@@ -2426,13 +2428,8 @@ static void dwc3_endpoint_transfer_complete(struct dwc3 
*dwc,
if (!dep->endpoint.desc)
return;
 
-   if (!usb_endpoint_xfer_isoc(dep->endpoint.desc)) {
-   int ret;
-
-   ret = __dwc3_gadget_kick_transfer(dep, 0);
-   if (!ret || ret == -EBUSY)
-   return;
-   }
+   if (!usb_endpoint_xfer_isoc(dep->endpoint.desc))
+   __dwc3_gadget_kick_transfer(dep);
 }
 
 static void dwc3_endpoint_interrupt(struct dwc3 *dwc,
@@ -2473,15 +2470,10 @@ static void dwc3_endpoint_interrupt(struct dwc3 *dwc,
dwc3_endpoint_transfer_complete(dwc, dep, event);
break;
case DWC3_DEPEVT_XFERNOTREADY:
-   if (usb_endpoint_xfer_isoc(dep->endpoint.desc)) {
+   if (usb_endpoint_xfer_isoc(dep->endpoint.desc))
dwc3_gadget_start_isoc(dwc, dep, event);
-   } else {
-   int ret;
-
-   ret = __dwc3_gadget_kick_transfer(dep, 0);
-   if (!ret || ret == -EBUSY)
-   return;
-   }
+   else
+   __dwc3_gadget_kick_transfer(dep);
 
break;
case DWC3_DEPEVT_STREAMEVT:
-- 
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

[PATCH 2/4] usb: dwc3: gadget: simplify __dwc3_gadget_ep_queue()

[Felipe Balbi]

There is more possibility for sharing code if we just realise that now
__dwc3_gadget_kic_transfer() knows to break out early if there are no
TRBs left.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index a943f6e00fe1..850fda013768 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1290,7 +1290,6 @@ static void dwc3_gadget_start_isoc(struct dwc3 *dwc,
 static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request 
*req)
 {
struct dwc3 *dwc = dep->dwc;
-   int ret = 0;
 
if (!dep->endpoint.desc) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
@@ -1337,24 +1336,14 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
}
 
if ((dep->flags & DWC3_EP_BUSY) &&
-   !(dep->flags & DWC3_EP_MISSED_ISOC)) {
-   WARN_ON_ONCE(!dep->resource_index);
-   ret = __dwc3_gadget_kick_transfer(dep,
- dep->resource_index);
-   }
-
-   goto out;
-   }
+   !(dep->flags & DWC3_EP_MISSED_ISOC))
+   goto out;
 
-   if (!dwc3_calc_trbs_left(dep))
return 0;
+   }
 
-   ret = __dwc3_gadget_kick_transfer(dep, 0);
 out:
-   if (ret == -EBUSY)
-   ret = 0;
-
-   return ret;
+   return __dwc3_gadget_kick_transfer(dep, 0);
 }
 
 static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
-- 
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

[PATCH 1/4] usb: dwc3: gadget: check for lack of TRBs a bit earlier

[Felipe Balbi]

This will let us call __dwc3_gadget_kick_transfer()
unconditionally. No functional changes, cleanup only.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f064f1549333..a943f6e00fe1 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1151,9 +1151,6 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep)
 
BUILD_BUG_ON_NOT_POWER_OF_2(DWC3_TRB_NUM);
 
-   if (!dwc3_calc_trbs_left(dep))
-   return;
-
/*
 * We can get in a situation where there's a request in the started list
 * but there weren't enough TRBs to fully kick it in the first time
@@ -1202,6 +1199,9 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep 
*dep, u16 cmd_param)
int ret;
u32 cmd;
 
+   if (!dwc3_calc_trbs_left(dep))
+   return 0;
+
starting = !(dep->flags & DWC3_EP_BUSY);
 
dwc3_prepare_trbs(dep);
-- 
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: Fibocom L831-EAU and cdc_mbim

[Bjørn Mork]

Andreas Böhler  writes:

> I recently bought a Thinkpad T470 notebook and added the Fibocom
> L831-EAU WWAN card. It's mbim-based, but unfortunately I can't get it
> to work correctly. In fact I'm experiencing similar issues to Patrick
> Chilton, who reported this behaviour a few months ago also on this
> list: https://www.spinics.net/lists/linux-usb/msg158286.html
>
> After a new boot, the card works for me for a few minutes, then all
> transfers stall. Finally, I receive the infamous 'cdc_mbim 1-6:1.0:
> nonzero urb status received: -EPIPE' message in my system log.
>
> I also tried to disable MBIM by adding an option to modprobe. During
> connect, pppd then just hangs up (again similar to what Patrick
> Chilton experienced).
>
> I'm on Arch Linux and Kernel 4.12.13, I tried with and without
> NetworkManager/ModemManager.
>
> Any ideas how I might be able to debug this?

Are you able to test the attached patch?  It should apply cleanly to any
of the 4.9, 4.12 and 4.13 stable trees.

Let me just admit that this is a long shot.  I don't actually understand
what happens here.  But I believe the problem started appearing with
v4.9, which had two patches touching this part of the driver in
suspicious ways.  One of those patches have already been reverted due to
other issues.  But the second is still present.  And I can't see
anything else which could possibly explain the problems.

If you can test this patch, then we can either confirm or refute this
theory.



Bjørn

>From 8fade48507bf4a017420acbe00b96ee2dc003efe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= 
Date: Mon, 18 Sep 2017 12:07:21 +0200
Subject: [PATCH] Revert "cdc-wdm: Clear read pipeline in case of error"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This reverts commit c1da59dad0ebd3f9bd238f3fff82b1f7ffda7829.

Some modem firmwares got stuck in an error state with the queued
error handling, never sending any data which would clear the
driver internal error state.

Fixes: c1da59dad0eb ("cdc-wdm: Clear read pipeline in case of error")
Signed-off-by: Bjørn Mork 
---
 drivers/usb/class/cdc-wdm.c | 39 ++-
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 5aacea1978a5..2b88eaa4089d 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -150,9 +150,6 @@ static void wdm_out_callback(struct urb *urb)
 	wake_up(>wait);
 }
 
-/* forward declaration */
-static int service_outstanding_interrupt(struct wdm_device *desc);
-
 static void wdm_in_callback(struct urb *urb)
 {
 	struct wdm_device *desc = urb->context;
@@ -187,13 +184,7 @@ static void wdm_in_callback(struct urb *urb)
 		}
 	}
 
-	/*
-	 * only set a new error if there is no previous error.
-	 * Errors are only cleared during read/open
-	 */
-	if (desc->rerr  == 0)
-		desc->rerr = status;
-
+	desc->rerr = status;
 	if (length + desc->length > desc->wMaxCommand) {
 		/* The buffer would overflow */
 		set_bit(WDM_OVERFLOW, >flags);
@@ -206,19 +197,9 @@ static void wdm_in_callback(struct urb *urb)
 		}
 	}
 skip_error:
-	set_bit(WDM_READ, >flags);
 	wake_up(>wait);
 
-	if (desc->rerr) {
-		/*
-		 * Since there was an error, userspace may decide to not read
-		 * any data after poll'ing.
-		 * We should respond to further attempts from the device to send
-		 * data, so that we can get unstuck.
-		 */
-		service_outstanding_interrupt(desc);
-	}
-
+	set_bit(WDM_READ, >flags);
 	spin_unlock(>iuspin);
 }
 
@@ -441,14 +422,17 @@ static ssize_t wdm_write
 }
 
 /*
- * Submit the read urb if resp_count is non-zero.
+ * clear WDM_READ flag and possibly submit the read urb if resp_count
+ * is non-zero.
  *
  * Called with desc->iuspin locked
  */
-static int service_outstanding_interrupt(struct wdm_device *desc)
+static int clear_wdm_read_flag(struct wdm_device *desc)
 {
 	int rv = 0;
 
+	clear_bit(WDM_READ, >flags);
+
 	/* submit read urb only if the device is waiting for it */
 	if (!desc->resp_count || !--desc->resp_count)
 		goto out;
@@ -540,8 +524,7 @@ static ssize_t wdm_read
 
 		if (!desc->reslength) { /* zero length read */
 			dev_dbg(>intf->dev, "zero length - clearing WDM_READ\n");
-			clear_bit(WDM_READ, >flags);
-			rv = service_outstanding_interrupt(desc);
+			rv = clear_wdm_read_flag(desc);
 			spin_unlock_irq(>iuspin);
 			if (rv < 0)
 goto err;
@@ -566,10 +549,8 @@ static ssize_t wdm_read
 
 	desc->length -= cntr;
 	/* in case we had outstanding data */
-	if (!desc->length) {
-		clear_bit(WDM_READ, >flags);
-		service_outstanding_interrupt(desc);
-	}
+	if (!desc->length)
+		clear_wdm_read_flag(desc);
 	spin_unlock_irq(>iuspin);
 	rv = cntr;
 
-- 
2.11.0

[PATCH 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Andrzej Pietrasiewicz]

From: Vivek Gautam 

Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.

We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by: Vivek Gautam 
[adapted to use phy_reset as entry point]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++
 drivers/usb/dwc3/core.c  |   8 +-
 2 files changed, 189 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 7c41daa..f7de067 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -89,7 +89,17 @@
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+#define PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define PHYREG0_SSC_RANGE  BIT(20)
+#define PHYREG0_CR_WRITE   BIT(19)
+#define PHYREG0_CR_READBIT(18)
+#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define PHYREG0_CR_CAP_DATABIT(1)
+#define PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
+#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define PHYREG1_CR_ACK BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
 
@@ -118,6 +128,25 @@
 #define EXYNOS5_DRD_PHYRESUME  0x34
 #define EXYNOS5_DRD_LINKPORT   0x44
 
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN (0x15)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420 (0x5 << 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT  (0x0 << 13)
+#define LOSLEVEL_OVRD_IN_EN(0x1 << 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT (0x9 << 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN   (0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420 (0x5 << 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT  (0x4 << 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG   (0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M(0x4 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M (0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M(0x40 << 4)
+
 #define KHZ1000
 #define MHZ(KHZ * KHZ)
 
@@ -526,6 +555,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
return 0;
 }
 
+static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+   u32 val, u32 cmd)
+{
+   u32 usec = 100;
+   unsigned int result;
+
+   writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (result & PHYREG1_CR_ACK)
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec) {
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout1 (0x%08x)\n", val);
+   return -ETIME;
+   }
+
+   usec = 100;
+
+   writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (!(result & PHYREG1_CR_ACK))
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec) {
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout2 (0x%08x)\n", val);
+   return -ETIME;
+   }
+
+   return 0;
+}
+
+static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+   u32 addr, u32 data)

Re: [PATCH resend 2/2] usb: phy: mxs: add usb charger type detection

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Mon, Sep 04, 2017 at 11:14:02PM +0800, Li Jun wrote:
>>  }
>>  
>> +#define MXS_USB_CHARGER_DATA_CONTACT_TIME_OUT   100
>
> How about using "DATA_CONTACT_TIMEOUT_LOOP"?

this really doesn't change anything. The only thing is that TIMEOUT is
more common than TIME_OUT. I'll make that change locally.

>> +static int mxs_charger_data_contact_detect(struct mxs_phy *x)
>> +{
>> +struct regmap *regmap = x->regmap_anatop;
>> +int i, stable_contact_count = 0;
>> +u32 val;
>> +
>> +/* Check if vbus is valid */
>> +regmap_read(regmap, ANADIG_USB1_VBUS_DET_STAT, );
>> +if (!(val & ANADIG_USB1_VBUS_DET_STAT_VBUS_VALID)) {
>> +dev_err(x->phy.dev, "vbus is not valid\n");
>> +return -EINVAL;
>> +}
>> +
>> +/* Enable charger detector */
>> +regmap_write(regmap, ANADIG_USB1_CHRG_DETECT_CLR,
>> +ANADIG_USB1_CHRG_DETECT_EN_B);
>> +/*
>> + * - Do not check whether a charger is connected to the USB port
>> + * - Check whether the USB plug has been in contact with each other
>> + */
>> +regmap_write(regmap, ANADIG_USB1_CHRG_DETECT_SET,
>> +ANADIG_USB1_CHRG_DETECT_CHK_CONTACT |
>> +ANADIG_USB1_CHRG_DETECT_CHK_CHRG_B);
>> +
>> +/* Check if plug is connected */
>> +for (i = 0; i < MXS_USB_CHARGER_DATA_CONTACT_TIME_OUT; i = i + 1) {
>
> We use i++ at for-loop usually.

this I can also fix while applying. Thanksn

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 1/2] ARM: dts: exynos: Add dwc3 SUSPHY quirk

[Andrzej Pietrasiewicz]

Odroid XU4 board does not enumerate SuperSpeed devices.
This patch makes exynos5 series chips use USB SUSPHY quirk,
which solves the problem.

Signed-off-by: Andrzej Pietrasiewicz 
---
 arch/arm/boot/dts/exynos54xx.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos54xx.dtsi 
b/arch/arm/boot/dts/exynos54xx.dtsi
index 0389e8a..8ca4fef 100644
--- a/arch/arm/boot/dts/exynos54xx.dtsi
+++ b/arch/arm/boot/dts/exynos54xx.dtsi
@@ -134,6 +134,7 @@
interrupts = ;
phys = <_phy0 0>, <_phy0 1>;
phy-names = "usb2-phy", "usb3-phy";
+   snps,dis_u3_susphy_quirk;
};
};
 
@@ -154,6 +155,7 @@
reg = <0x1240 0x1>;
phys = <_phy1 0>, <_phy1 1>;
phy-names = "usb2-phy", "usb3-phy";
+   snps,dis_u3_susphy_quirk;
};
};
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] dwc3 on XU3 and XU4

[Andrzej Pietrasiewicz]

Hi all,

this short series addresses two issues.

The first issue is devices not enumerating when connected to an Odroid XU4,
to its 3.0 root hub. The interplay between refactoring certain parts of
dwc3's code and handling the SUSPHY quirk results in the said problem.
Please see: https://patchwork.kernel.org/patch/9535235/
Actually using the quirk solves it.

The second issue is devices not enumerating and/or wrongly enumerating
as high speed instead of super speed on an Odroid XU3. There was a patch
series from Vivek Gautam in circulation, but it got lost somehow.
Please see:

https://lkml.org/lkml/2014/9/2/166
https://lkml.org/lkml/2015/2/2/257

I adapted his patch so that it does not use a hacky solution to force
additional initialization in order for calibration to happen.
Instead I used the .reset() in phy_ops. I could have used the .set_mode(),
but the calibration must happen only after dwc3_host_init() but
phy_set_mode() is called either after of before it. With this patch
enumeration happens correctly and a super speed device is recognized as such.

Rebased onto v4.13. It also applies cleanly to Felipe's testing/next.

Andrzej Pietrasiewicz (1):
  ARM: dts: exynos: Add dwc3 SUSPHY quirk

Vivek Gautam (1):
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 arch/arm/boot/dts/exynos54xx.dtsi|   2 +
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++
 drivers/usb/dwc3/core.c  |   8 +-
 3 files changed, 191 insertions(+), 2 deletions(-)

-- 
1.9.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 v2 5/9] mtd: nand: atmel: Report PMECC failures as errors

[Boris Brezillon]

Hi Romain,

On Fri, 15 Sep 2017 16:04:07 +0200
Romain Izard  wrote:

> It is not normal for the PMECC to fail when trying to fix ECC errors.
> Report these cases as errors.

I'm not sure we want to have ECC error messages at this level. ECC
errors are rather unusual but not impossible, and sometimes it's even
not a real error (I'm thinking of bitflips in erased pages for
example, which are not necessarily detected/fixed in hardware).

If we decide to print error messages when unfixable bitflips are
detected, it should be done in the nand-controller driver (somewhere
along those lines [1]).

Regards,

Boris

[1]http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/atmel/nand-controller.c#L827

> 
> Signed-off-by: Romain Izard 
> ---
>  drivers/mtd/nand/atmel/pmecc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/atmel/pmecc.c b/drivers/mtd/nand/atmel/pmecc.c
> index 8d1208f38025..2a23f1ff945f 100644
> --- a/drivers/mtd/nand/atmel/pmecc.c
> +++ b/drivers/mtd/nand/atmel/pmecc.c
> @@ -687,6 +687,8 @@ static int atmel_pmecc_err_location(struct 
> atmel_pmecc_user *user)
>* Number of roots does not match the degree of smu
>* unable to correct error.
>*/
> + dev_err(pmecc->dev,
> + "PMECC: Impossible to calculate error location.\n");
>   return -EBADMSG;
>  }
>  
> @@ -729,7 +731,7 @@ int atmel_pmecc_correct_sector(struct atmel_pmecc_user 
> *user, int sector,
>   ptr = ecc + byte - sectorsize;
>   area = "ECC";
>   } else {
> - dev_dbg(pmecc->dev,
> + dev_err(pmecc->dev,
>   "Invalid errpos value (%d, max is %d)\n",
>   errpos, (sectorsize + eccbytes) * 8);
>   return -EINVAL;

--
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 4/9] mtd: nand: atmel: Avoid ECC errors when leaving backup mode

[Boris Brezillon]

Hi Romain,

On Fri, 15 Sep 2017 16:04:06 +0200
Romain Izard  wrote:

> During backup mode, the contents of all registers will be cleared as the
> SoC will be completely powered down. For a product that boots on NAND
> Flash memory, the bootloader will obviously use the related controller
> to read the Flash and correct any detected error in the memory, before
> handling back control to the kernel's resuming entry point.
> 
> In normal devices, it is up to the driver's suspend/resume code to
> restore the registers in a valid state. But the PMECC is not a regular
> device in the driver model when used with the legacy device tree binding
> for the Atmel NAND controller, and suspend/resume code is not called.
> 
> As in my case the bootloader leaves the PMECC controller in a programmed
> state, and the controller is only reset at boot or after a NAND access,
> the first NAND Flash access with the Atmel controller will report
> uncorrectable ECC errors.
> 
> To avoid this, systematically reset the PMECC controller before using
> it.
> 
> Signed-off-by: Romain Izard 
> ---
>  drivers/mtd/nand/atmel/pmecc.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mtd/nand/atmel/pmecc.c b/drivers/mtd/nand/atmel/pmecc.c
> index 8c210a5776bc..8d1208f38025 100644
> --- a/drivers/mtd/nand/atmel/pmecc.c
> +++ b/drivers/mtd/nand/atmel/pmecc.c
> @@ -777,6 +777,9 @@ int atmel_pmecc_enable(struct atmel_pmecc_user *user, int 
> op)
>  
>   mutex_lock(>pmecc->lock);
>  
> + writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> + writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> +
>   cfg = user->cache.cfg;
>   if (op == NAND_ECC_WRITE)
>   cfg |= PMECC_CFG_WRITE_OP;
> @@ -797,10 +800,6 @@ EXPORT_SYMBOL_GPL(atmel_pmecc_enable);
>  
>  void atmel_pmecc_disable(struct atmel_pmecc_user *user)
>  {
> - struct atmel_pmecc *pmecc = user->pmecc;
> -
> - writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> - writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);

So know you leave the ECC engine enabled even when it's not in use? Not
sure what kind of implication this has on power-consumption, but I
think I'd prefer to keep the write RST+DISABLE sequence in the disable
path.

How about creating a atmel_pmecc_reset() function that you'd call from
the nand-controller resume hook. Something like:

void atmel_pmecc_reset(struct atmel_pmecc *pmecc)
{
writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
}

This way you can re-use the same function and call it from the probe
and disable path as well.

Regards,

Boris

>   mutex_unlock(>pmecc->lock);
>  }
>  EXPORT_SYMBOL_GPL(atmel_pmecc_disable);
> @@ -856,10 +855,6 @@ static struct atmel_pmecc *atmel_pmecc_create(struct 
> platform_device *pdev,
>   /* Disable all interrupts before registering the PMECC handler. */
>   writel(0x, pmecc->regs.base + ATMEL_PMECC_IDR);
>  
> - /* Reset the ECC engine */
> - writel(PMECC_CTRL_RST, pmecc->regs.base + ATMEL_PMECC_CTRL);
> - writel(PMECC_CTRL_DISABLE, pmecc->regs.base + ATMEL_PMECC_CTRL);
> -
>   return pmecc;
>  }
>  

--
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] USB: serial: cp210x.c -fix partnum regression for devices not having a part number

[Johan Hovold]

On Tue, Sep 12, 2017 at 09:50:59AM +0200, Sebastian Frei wrote:
> When adding GPIO support for the cp2105, the mentioned commit by Martyn
> Welch introduced a query for the part number of the chip. Unfortunately the
> driver aborts loading when this query fails, so currently the driver can not
> be used with chips not supporting this query.
> I have a data cable for Siemens mobile phones (ID 10ab:10c5) where this is the
> case.
> With this patch the driver can be loaded even if the part number can not be
> queried.

I edited the above slightly before applying replacing "loading" with
"probing" and "loaded" with "bound" which are the terms we use for
the process of binding a driver to a new device.

Also try to keep your commit summaries (mail Subject) below 72 cols or
so.

> Fixes: cf5276ce7867 ("USB: serial: cp210x: Adding GPIO support for CP2105")
> Signed-off-by: Sebastian Frei 
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index 2d945c9f975c..a3e301b1eb73 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -352,6 +352,7 @@ static struct usb_serial_driver * const serial_drivers[] 
> = 
> {

This patch did not apply due to the above line wrapped. It was easy
enough to fix this time, but please make sure your mail setup does not
corrupt patches in the future.

>  #define CP210X_PARTNUM_CP21040x04
>  #define CP210X_PARTNUM_CP21050x05
>  #define CP210X_PARTNUM_CP21080x08
> +#define CP210X_PARTNUM_UNKNOWN   0xFF
>  
>  /* CP210X_GET_COMM_STATUS returns these 0x13 bytes */
>  struct cp210x_comm_status {
> @@ -1488,13 +1489,17 @@ static int cp210x_attach(struct usb_serial *serial)
>   if (!priv)
>   return -ENOMEM;
>  
> + usb_set_serial_data(serial, priv);
> +

Moving usb_set_serial_data() is no longer needed with the changes you
did in v3 so I dropped this part of the change.

>   result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
> CP210X_GET_PARTNUM, >partnum,
> sizeof(priv->partnum));
> - if (result < 0)
> - goto err_free_priv;
>  
> - usb_set_serial_data(serial, priv);
> + if (result < 0) {
> + dev_err(>interface->dev,
> + "querying part number failed, continuing anyways\n");

And shortened this error message.

> + priv->partnum = CP210X_PARTNUM_UNKNOWN;
> + }
>  
>   if (priv->partnum == CP210X_PARTNUM_CP2105) {
>   result = cp2105_shared_gpio_init(serial);
> @@ -1505,10 +1510,6 @@ static int cp210x_attach(struct usb_serial *serial)
>   }
>  
>   return 0;
> -err_free_priv:
> - kfree(priv);
> -
> - return result;
>  }
>  
>  static void cp210x_disconnect(struct usb_serial *serial)
> 

Thanks for finding and fixing this regression.

Johan
--
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 1/5] staging: typec: tcpm: Drop commented out code

[Greg Kroah-Hartman]

On Tue, Sep 12, 2017 at 09:41:20AM -0700, Guenter Roeck wrote:
> On Tue, Sep 12, 2017 at 10:38:39AM +0300, Heikki Krogerus wrote:
> > On Mon, Sep 11, 2017 at 08:32:04PM -0700, Guenter Roeck wrote:
> > > Commented out code can be added as needed. Drop it.
> > > Also drop TODO and an obsolete XXX comment.
> > > 
> > > Signed-off-by: Guenter Roeck 
> > > ---
> > > v2, v3: No change
> > > 
> > >  drivers/staging/typec/tcpm.c | 37 +
> > >  1 file changed, 1 insertion(+), 36 deletions(-)
> > 
> > Nice! Just to be sure: The idea is to leave tcpci.c in staging, right?
> > 
> Yes, until we get test coverage or Greg gets tired of keeping it there
> (in that case we would probably have to drop it).

Well, if it's not ever going to get fixed up, why can't we just drop it?

Anyway, I've pulled this series into the staging and USB trees, so all
should be good for it now.

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 v4 0/3] initialize (multiple) PHYs in xhci-plat

[Greg KH]

On Sun, Sep 17, 2017 at 10:51:31PM +0200, Martin Blumenstingl wrote:
> Hello Mathias, Hello Greg,
> 
> On Sun, Sep 3, 2017 at 11:38 PM, Martin Blumenstingl
>  wrote:
> > This series is the outcome of a discussion with Felipe Balbi,
> > see [0] and [1].
> > The quick-summary of this is:
> > - dwc3 already takes one USB2 and one USB3 PHY and initializes these
> >   correct
> > - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and
> >   ohci-platform.c) do not have a limitation on the number of PHYs - they
> >   support one PHY per actual host port
> > - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two
> >   or three USB2 ports enabled on the internal root-hub. The SoCs also
> >   provide separate USB2 PHYs, one per port. All USB2 PHYs (which are
> >   internally "connected" to the dwc3 roothub) need to be powered on,
> >   otherwise USB devices cannot be enumerated (even if just one PHY is
> >   disabled and if the device is plugged into another, enabled port)
> >
> > In my first attempt to get USB supported on the GXL and GXM SoCs I tried
> > to work-around the problem that I could not pass multiple PHYs to the
> > dwc3 controller.
> > This was rejected by Rob Herring (which was definitely the thing to do in
> > my opinion), see [2]
> >
> > This series adds a new "platform-roothub". This can be configured through
> > devicetree by passing a child-node with "reg = <0>" to the USB
> > controller. Additionally there has to be a child-node for each port on
> > the root-hub. Each of the child-nodes takes a "phys" and "phy-names"
> > property. This allows modeling the root-hub in devicetree similar to the
> > USB device binding (documented in devicetree/bindings/usb/usb-device.txt)
> > This avoids and backwards-compatibility problems (which was a concern
> > regardless of the solution, see [3]) since the binding for the root-hub
> > was previously not specified (and we're not using the "phys" property of
> > the controller, which might have served different purposes before,
> > depending on the drivers).
> >
> > Additionally this integrates the new platform-roothub into xhci-plat.c
> > which automatically enables it for the dwc3 driver (in host-mode).
> >
> >
> > Changes since RFCv3 at [6]:
> > - moved the DT binding change from patch #3 to patch #1 as suggested
> >   by Rob Herring (and slightly adjusted the commit message to account
> >   for that)
> > - added Tested-by from Chunfeng Yun (who confirmed that the whole
> >   concept and implementation works fine on Mediatek SoCs - many thanks
> >   again!) to patch #2
> > - added Rob Herring's ACK to patches 1 and 3
> > - dropped RFC status (RFCv3 -> PATCH v4)
> I just wanted to rebase this to v4.14-rc1 (now that this is out) -
> however I noticed that v4 still applies to v4.14-rc1 cleanly (the
> patches are still identical to v4 after rebasing).
> 
> we have an ACK from the devicetree maintainers and a "Tested-by" for a
> Mediatek (= non-Amlogic) SoC.
> I already have patches for the Amlogic GXL/GXM platforms queued, those
> are just waiting on this series.
> 
> what is still missing to get this series into v4.15?

Well, we couldn't do anything until 4.14-rc1 is out, now that it is, let
us catch up on patch review please...

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: [regression] Force hard reset of Renesas uPD72020x USB controller

[Albert Weichselbraun]

Hi Marc,

100% ack
- Booting with a kernel that does not do a PCI reset yields the
  following topology:


-[:00] -
 +-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM
 Controller
 +-02.0  Intel Corporation 2nd Generation Core Processor Family
 Integrated Graphics Controller
 +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI
 Controller #1
 +-19.0  Intel Corporation 82579LM Gigabit Network Connection
 +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
 Enhanced Host Controller #2
 +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High
 Definition Audio Controller
 +-1c.0-[02]--
 +-1c.1-[03]00.0  Intel Corporation Centrino Advanced-N 6205
  [Taylor Peak]
 +-1c.3-[05-0c]00.0  Renesas Technology Corp. uPD720202 USB 3.0
 Host Controller
 +-1c.4-[0d]00.0  Ricoh Co Ltd MMC/SD Host Controller
 +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
 Enhanced Host Controller #1
 +-1f.0  Intel Corporation QM67 Express Chipset Family LPC Controller
 +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6 port
 SATA AHCI Controller
 \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family SMBus
 Controller


Unplugging and replugging the card (regardless of the kernel version)
or booting with a kernel that does the reset leads to the card not
being correctly recognized and the problems I have observed.


-[:00]-
 +-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM
 Controller
 +-02.0  Intel Corporation 2nd Generation Core Processor Family
 Integrated Graphics Controller
 +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI
 Controller #1
 +-19.0  Intel Corporation 82579LM Gigabit Network Connection
 +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
 Enhanced Host Controller #2
 +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High
 Definition Audio Controller
 +-1c.0-[02]--
 +-1c.1-[03]00.0  Intel Corporation Centrino Advanced-N 6205
  [Taylor Peak]
 +-1c.3-[05-0c]--
 +-1c.4-[0d]00.0  Ricoh Co Ltd MMC/SD Host Controller
 +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB
 Enhanced Host Controller #1
 +-1f.0  Intel Corporation QM67 Express Chipset Family LPC Controller
 +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6 port
 SATA AHCI Controller
 \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family SMBus
 Controller


Cheers
  Albert :)


On Mon, 2017-09-18 at 09:15 +0100, Marc Zyngier wrote:
> Hi Albert,
> 
> On 17/09/17 13:39, Albert Weichselbraun wrote:
> > Dear all,
> > 
> > I ran into a regression with an ExpressCard/54 USB 3.0 expansion
> > card
> > that uses the Renesas uPD72020x chipset on a Lenovo X220i Laptop
> > (the
> > described behavior has been reproduced with kernel versions 4.12.8,
> > 4.12.13, 4.13.1 and 4.13.2).
> > 
> > Once booting such a kernel, the system becomes very sluggish with
> > considerable mouse pointer delays that are followed by display
> > driver
> > errors such as
> >  - pipe A vblank wait timed out
> >  - pipe B vblank wait timed out
> > after some minutes.
> > 
> > Please refer to 
> >   https://weichselbraun.net/tmp/dmesg-pipe-a-vblank-timeout.log
> >   https://weichselbraun.net/tmp/dmesg-pipe-b-vblank-timeout.log
> > for the corresponding log messages.
> > 
> > Removing the expansion card or booting with a pre 4.12.8 kernel
> > resolves the issue.
> > 
> > I traced the problem back to the following patch that has been
> > introduced in 4.12.8 and seems to force a PCI reset on the device. 
> > 
> 
> [...]
> 
> > What seems to happen on my machine is that the reset fails leaving
> > the
> > device in an undefined state:
> > 
> > 
> > Sep 17 08:35:19 trinity kernel: [2.874329] xhci_hcd
> > :05:00.0: 
> >   xHCI host controller not responding, assume dead
> > Sep 17 08:35:19 trinity kernel: [2.874341] xhci_hcd
> > :05:00.0: 
> >   remove, state 1
> > Sep 17 08:35:19 trinity kernel: [2.874350] usb usb4: USB 
> >   disconnect, device number 1
> > Sep 17 08:35:19 trinity kernel: [2.874608] xhci_hcd
> > :05:00.0: 
> >   USB bus 4 deregistered
> > Sep 17 08:35:19 trinity kernel: [2.875433] xhci_hcd
> > :05:00.0: 
> >   remove, state 1
> > Sep 17 08:35:19 trinity kernel: [2.875440] usb usb3: USB 
> >   disconnect, device number 1
> > Sep 17 08:35:19 trinity kernel: [2.875535] clocksource:
> > Switched
> > to 
> >   clocksource tsc
> > Sep 17 08:35:19 trinity kernel: [2.875769] xhci_hcd
> > :05:00.0: 
> >   Host halt failed, -19
> > Sep 17 08:35:19 trinity kernel: [2.875777] xhci_hcd
> > :05:00.0: 
> >   Host not accessible, reset failed.
> > Sep 17 08:35:19 trinity kernel: [2.876148] xhci_hcd
> > :05:00.0: 
> >   USB bus 3 

Re: [PATCH] USB: serial: option: add support for TP-Link LTE module

[Johan Hovold]

On Mon, Sep 11, 2017 at 05:57:34PM +0200, Henryk Heisig wrote:
> This commit adds support for TP-Link LTE mPCIe module is used
> in in TP-Link MR200v1, MR6400v1 and v2 routers.
> 
> Signed-off-by: Henryk Heisig 

Now applied, thanks.

Johan
--
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 v9] usb: serial: add vid:pid for Cypress WICED dev board

[Johan Hovold]

On Fri, Sep 08, 2017 at 09:08:58PM +, Sheng-Hui J. Chu wrote:
> From: Jeffrey Chu 
> 
> Add CYPRESS_VID vid and CYPRESS_WICED_BT_USB and CYPRESS_WICED_WL_USB
> device IDs to ftdi_sio driver
> 
> Signed-off-by: Jeffrey Chu 

I have two v9 of this patch in my mailbox with different authorship and
sent five minutes apart. I figured you really wanted this last one
applied, but next time make sure to increase the patch revision (e.g.
mark it as v10) to avoid any confusion.

> ---
>  drivers/usb/serial/ftdi_sio.c | 2 ++
>  drivers/usb/serial/ftdi_sio_ids.h | 7 +++
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 1cec037..49d1b2d 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1015,6 +1015,8 @@ static const struct usb_device_id id_table_combined[] = 
> {
>   { USB_DEVICE(WICED_VID, WICED_USB20706V2_PID) },
>   { USB_DEVICE(TI_VID, TI_CC3200_LAUNCHPAD_PID),
>   .driver_info = (kernel_ulong_t)_jtag_quirk },
> + { USB_DEVICE(CYPRESS_VID, CYPRESS_WICED_BT_USB_PID) },
> + { USB_DEVICE(CYPRESS_VID, CYPRESS_WICED_WL_USB_PID) },
>   { } /* Terminating entry */
>  };
>  
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
> b/drivers/usb/serial/ftdi_sio_ids.h
> index 4fcf1ce..d58dc1b 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -692,6 +692,13 @@
>  #define WICED_USB20706V2_PID 0x6422
>  
>  /*
> + * Cypress WICED USB UART
> + */
> +#define CYPRESS_VID  0x04B4
> +#define CYPRESS_WICED_BT_USB_PID 0x009B
> +#define CYPRESS_WICED_WL_USB_PID 0xF900
> +
> +/*
>   * Definitions for ID TECH (www.idt-net.com) devices
>   */
>  #define IDTECH_VID   0x0ACD  /* ID TECH Vendor ID */

I've applied this one now with some minor tweaks (e.g. kept the define
sections sorted by VID, and adjusted the commit message slightly).

Thanks,
Johan
--
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 resend 2/2] usb: phy: mxs: add usb charger type detection

[Peter Chen]

On Mon, Sep 04, 2017 at 11:14:02PM +0800, Li Jun wrote:
>  }
>  
> +#define MXS_USB_CHARGER_DATA_CONTACT_TIME_OUT100

How about using "DATA_CONTACT_TIMEOUT_LOOP"?

> +static int mxs_charger_data_contact_detect(struct mxs_phy *x)
> +{
> + struct regmap *regmap = x->regmap_anatop;
> + int i, stable_contact_count = 0;
> + u32 val;
> +
> + /* Check if vbus is valid */
> + regmap_read(regmap, ANADIG_USB1_VBUS_DET_STAT, );
> + if (!(val & ANADIG_USB1_VBUS_DET_STAT_VBUS_VALID)) {
> + dev_err(x->phy.dev, "vbus is not valid\n");
> + return -EINVAL;
> + }
> +
> + /* Enable charger detector */
> + regmap_write(regmap, ANADIG_USB1_CHRG_DETECT_CLR,
> + ANADIG_USB1_CHRG_DETECT_EN_B);
> + /*
> +  * - Do not check whether a charger is connected to the USB port
> +  * - Check whether the USB plug has been in contact with each other
> +  */
> + regmap_write(regmap, ANADIG_USB1_CHRG_DETECT_SET,
> + ANADIG_USB1_CHRG_DETECT_CHK_CONTACT |
> + ANADIG_USB1_CHRG_DETECT_CHK_CHRG_B);
> +
> + /* Check if plug is connected */
> + for (i = 0; i < MXS_USB_CHARGER_DATA_CONTACT_TIME_OUT; i = i + 1) {

We use i++ at for-loop usually.

-- 

Best Regards,
Peter Chen
--
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: serial: cp210x: add support for ELV TFD500

[Johan Hovold]

On Sun, Sep 03, 2017 at 12:04:40PM +0200, Andreas Engel wrote:
> Add the USB device id for the ELV TFD500 data logger.
> 
> Signed-off-by: Andreas Engel 
> ---
>  drivers/usb/serial/cp210x.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index 2d945c9f975c..bd8574ca32aa 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -177,6 +177,7 @@ static const struct usb_device_id id_table[] = {
> { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
> { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
> { USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */
> +   { USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */
> { USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */
> { USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */
> { USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */

This patch is whitespace damaged (tabs replaced with spaces) and does
not apply.

Take a look at git-send-email, and please try sending it to yourself
first to make sure your mail setup no longer corrupts the patch.

Thanks,
Johan
--
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: [regression] Force hard reset of Renesas uPD72020x USB controller

[Marc Zyngier]

Hi Albert,

On 17/09/17 13:39, Albert Weichselbraun wrote:
> Dear all,
> 
> I ran into a regression with an ExpressCard/54 USB 3.0 expansion card
> that uses the Renesas uPD72020x chipset on a Lenovo X220i Laptop (the
> described behavior has been reproduced with kernel versions 4.12.8,
> 4.12.13, 4.13.1 and 4.13.2).
> 
> Once booting such a kernel, the system becomes very sluggish with
> considerable mouse pointer delays that are followed by display driver
> errors such as
>  - pipe A vblank wait timed out
>  - pipe B vblank wait timed out
> after some minutes.
> 
> Please refer to 
>   https://weichselbraun.net/tmp/dmesg-pipe-a-vblank-timeout.log
>   https://weichselbraun.net/tmp/dmesg-pipe-b-vblank-timeout.log
> for the corresponding log messages.
> 
> Removing the expansion card or booting with a pre 4.12.8 kernel
> resolves the issue.
> 
> I traced the problem back to the following patch that has been
> introduced in 4.12.8 and seems to force a PCI reset on the device. 
> 

[...]

> What seems to happen on my machine is that the reset fails leaving the
> device in an undefined state:
> 
> 
> Sep 17 08:35:19 trinity kernel: [2.874329] xhci_hcd :05:00.0: 
>   xHCI host controller not responding, assume dead
> Sep 17 08:35:19 trinity kernel: [2.874341] xhci_hcd :05:00.0: 
>   remove, state 1
> Sep 17 08:35:19 trinity kernel: [2.874350] usb usb4: USB 
>   disconnect, device number 1
> Sep 17 08:35:19 trinity kernel: [2.874608] xhci_hcd :05:00.0: 
>   USB bus 4 deregistered
> Sep 17 08:35:19 trinity kernel: [2.875433] xhci_hcd :05:00.0: 
>   remove, state 1
> Sep 17 08:35:19 trinity kernel: [2.875440] usb usb3: USB 
>   disconnect, device number 1
> Sep 17 08:35:19 trinity kernel: [2.875535] clocksource: Switched
> to 
>   clocksource tsc
> Sep 17 08:35:19 trinity kernel: [2.875769] xhci_hcd :05:00.0: 
>   Host halt failed, -19
> Sep 17 08:35:19 trinity kernel: [2.875777] xhci_hcd :05:00.0: 
>   Host not accessible, reset failed.
> Sep 17 08:35:19 trinity kernel: [2.876148] xhci_hcd :05:00.0: 
>   USB bus 3 deregistered
> 
> 
> The full dmesg output is available at
>   https://weichselbraun.net/tmp/dmesg-4.13.2-unpatched
> 
> Reverting the changes (tested on 4.12.8, 4.13.1 and 4.13.2) solves this
> issue on my system.  
>   https://weichselbraun.net/tmp/dmesg-4.13.2-patched
>  
> lspci:
>   05:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 
> Host Controller (rev 02)
> 
> Please let me know if there is any additional information I can provide
> to help narrowing this down.

Thanks for the detailed report.

I wonder if the hotplug nature of the card could be playing some tricks
on us, and the PCI reset nuking some otherwise important programming
that are relevant to the ExpressCard bridge.

Do you get the same effect if you're plugging the card after the system
has booted? Could you please post your full PCI topology (lspci -vt)?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
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: dwc3: Fix the USB 3.0 hub detection bug after warm boot

[Felipe Balbi]

Hi,

gustavo panizzo  writes:
>>>gustavo panizzo  writes:
>>>---
>>>drivers/usb/dwc3/core.c | 33 +
>>>1 file changed, 33 insertions(+)
>>>
>>>diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>index 326b302fc440..f92dfe213d89 100644
>>>--- a/drivers/usb/dwc3/core.c
>>>+++ b/drivers/usb/dwc3/core.c
>>>@@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device
>>>*pdev)
>>>   return ret;
>>>}
>>>
>>>+static void dwc3_shutdown(struct platform_device *pdev)
>>>+{
>>>+   struct dwc3 *dwc = platform_get_drvdata(pdev);
>>>+   struct resource *res = platform_get_resource(pdev,
>>>IORESOURCE_MEM, 0);
>>>+
>>>+   pm_runtime_get_sync(>dev);
>>>+   /*
>>>+* restore res->start back to its original value so that, in 
>>>case
>>>the
>>>+* probe is deferred, we don't end up getting error in 
>>>request
>>>the
>>>+* memory region the next time probe is called.
>>>+*/
>>>+   res->start -= DWC3_GLOBALS_REGS_START;
>>>+
>>>+   dwc3_debugfs_exit(dwc);
>>>+   dwc3_core_exit_mode(dwc);
>>>+   dwc3_event_buffers_cleanup(dwc);
>
>
>What about dwc3_event_buffers_cleanup? should I remove it from
>dwc3_shutdown()?
>It is already in dwc3_core_exit()

I think so. We should avoid duplicate code.

>>>+   dwc3_free_event_buffers(dwc);
>>>+
>>>+   usb_phy_set_suspend(dwc->usb2_phy, 1);
>>>+   usb_phy_set_suspend(dwc->usb3_phy, 1);
>>>+
>>>+   phy_power_off(dwc->usb2_generic_phy);
>>>+   phy_power_off(dwc->usb3_generic_phy);
>>
>>
>>We've done these in dwc3_core_exit().
>>>
>>>This is the patch after testing on a Odroid XU4, on top of linux-next
>>>964bcc1b4f57028d56dace7d9bc5924f2eb43f36 which translates to 
>>>4.13.0-rc1-next-20170717+
>>>I tested this patch for a week without problems with heavy USB and NIC 
>>>usage.
>>>Please consider merging it

Author: Brian Kim 
Date:   Wed Jul 12 11:26:55 2017 +0800

   usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot
   The dwc3 could not release resources when the module is built-in
   because this module does not have shutdown method. This causes the USB
   3.0 hub is not able to detect after warm boot.
   Original patch by Brian Kim, updated and submitted upstream by gustavo
   panizzo.
   Also see https://bugs.debian.org/843448
   Signed-off-by: Brian Kim 
   Signed-off-by: gustavo panizzo 

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302fc440..09de37d47ee7 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1259,6 +1259,32 @@ static int dwc3_probe(struct platform_device *pdev)
return ret;
}

+static void dwc3_shutdown(struct platform_device *pdev)
+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 
0);
+
+   pm_runtime_get_sync(>dev);
+   /*
+* restore res->start back to its original value so that, in case 
the
+* probe is deferred, we don't end up getting error in request the
+* memory region the next time probe is called.
+*/
+   res->start -= DWC3_GLOBALS_REGS_START;
+
+   dwc3_debugfs_exit(dwc);
+   dwc3_core_exit_mode(dwc);
+   dwc3_event_buffers_cleanup(dwc);
+   dwc3_free_event_buffers(dwc);
+
+   dwc3_core_exit(dwc);
+   dwc3_ulpi_exit(dwc);
+
+   pm_runtime_put_sync(>dev);
+   pm_runtime_allow(>dev);
+   pm_runtime_disable(>dev);
+}
+
static int dwc3_remove(struct platform_device *pdev)
{
struct dwc3 *dwc = platform_get_drvdata(pdev);
@@ -1488,6 +1514,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = dwc3_remove,
+   .shutdown   = dwc3_shutdown,
.driver = {
.name   = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),

Patch applies cleanly on top of c6be5a0e3cebc145127d46a58350e05d2bcf6323 
from linux-next
Can you _please_ merge it?
>>>
>>>why are you upset? You didn't do the changes I requested until now. It's
>>
>>I'm not 

Re: [PATCH] Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"

[Mathias Nyman]

On 16.09.2017 07:49, Kai-Heng Feng wrote:

On Mon, Aug 28, 2017 at 9:56 PM, Kai-Heng Feng
 wrote:

On Mon, Aug 28, 2017 at 6:14 PM, Mathias Nyman
 wrote:

On 28.08.2017 12:29, Greg KH wrote:

Adding more people who were involved in the original patch.

Users are now seeing the unresponsive USB2 ports with Promontory hosts.
Is there any update on a better way to solve the original issue.

To me a "dead" USB2 port seems like a much worse issue for a user
than a BIOS disabled port waking up on plug/unplug (wake on
connect/disconnect),
so I'm myself in favor of doing this revert.


At least I can't find "Disable USB2" on my ASUS PRIME B350M-A, so the
new behavior is quite surprising.



But there was a strong push from Promontory developers to get the original
fix in,
and I would like to get some comment from them before I do anything about
it.


You looped them to the mail thread which I reported the regression two
weeks ago, and there is no response since then...


Still no response from AMD and ASMedia guys.

I don't like to use out-of-tree patches for myself, but probably it's
the only way here?


I'll revert it and send it forward now since rc1 is out

-Mathias

--
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: incomplete MJPG frames through dwc2 USB host

[Minas Harutyunyan]

Hi Andrea,

On 9/15/2017 1:34 PM, Andrea Di Chiara wrote:
> Hi,
> I'm using a RK3288 rockchip board whit kernel rockchip-linux release-4.4.
> It has two USB host and one of them has a DW controller. If I connect a
> UVC camera on it, I get into an incomplete MJPG frame error when enable
> stream with a image format greater or equal than 1920x1080. There isn't
> any related error on dmseg log, even if I enable CONFIG_USB_DWC2_DEBUG.
> So I can check that issue only processing MJPG data or showing that frame.
>
> I'm certain it isn't a camera problem cause if I connect it to the other
> ECHI controller USB port it work properly. I thought it was an bandwidth
> issue cause if I reduce image format the problem disappear. Could it be
> so? If not, what could it be the problem?
>
> This is rk3288.dtsi usb hosts config
>
> usb_host0_ehci: usb@ff50 {
> compatible = "generic-ehci";
> reg = <0xff50 0x100>;
> interrupts = ;
> clocks = < HCLK_USBHOST0>;
> clock-names = "usbhost";
> phys = <>;
> phy-names = "usb";
> status = "disabled";
> };
>
> usb_host1: usb@ff54 {
> compatible = "rockchip,rk3288-usb", "rockchip,rk3066-usb",
> "snps,dwc2";
> reg = <0xff54 0x4>;
> interrupts = ;
> clocks = < HCLK_USBHOST1>;
> clock-names = "otg";
> dr_mode = "host";
> phys = <>;
> phy-names = "usb2-phy";
> status = "disabled";
> };
>
> thank you for the attention,
> best regards
> Andrea
>
>
>
> Software Department
> softw...@teseo.com
>
> -
> TESEO spavia Agnelli, 49  63900 FERMO (FM) ITALY
> Tel. +39 0734 628818   --Fax. +39 0734 628816
>
> Disclaimer: This electronic mail transmission may contain legally privileged 
> and/or confidential information. Do not read this if you are not the 
> person(s) named. Any use, distribution, copying or disclosure by any other 
> person is strictly prohibited. If you receive this transmission by mistake 
> destroy the original transmission and its attachments without reading or 
> saving in any manner.
> --
> 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  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_majordomo-2Dinfo.html=DwIDaQ=DPL6_X_6JkXFx7AXWqB0tg=6z9Al9FrHR_ZqbbtSAsD16pvOL2S3XHxQnSzq8kusyI=njoBgj7h5w8eomFq_6xzn10dBtuDtjftyZbxdGCjgEI=ZQGDeZanbc8q01Cfi_sFgKWlOlgi9DAKmvkuyHQaHNI=
>

Could you please provide more details on observed issue. In which mode 
dwc core works: Slave, Buffer DMA or Descriptor DMA? USB speed: high or 
full? Split transfers? ISOC IN EP details: max packet size, number of 
additional packets? Packet count per (micro)frame and average total 
transfer size in (micro)frame in case of 1920x1080? dmesg log also will 
be usefull.

Thanks,
Minas

--
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