Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Mon, 10 Jul 2017 14:34:27 +0200
Johan Hovold jo...@kernel.org wrote:
>On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
>> On Fri, 07 Jul 2017 09:48:48 +0200
>> Bjørn Mork bj...@mork.no wrote:
>>
>> >[adding Johan on the CC list]
>> >
>> >Anatolij Gustschin writes:
>> >
>> >> +static struct usb_device_id ftdi_mfd_table[] = {
>> >> + { USB_DEVICE(0x0403, 0x6014) },
>> >> + {}
>> >> +};
>> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
>> >
>> >This device ID is currently handled by the ftdi_sio driver, so I believe
>> >you at least have to explain how you intend these two drivers to
>> >cooperate...
>>
>> these drivers cannot cooperate, the different ftdi function modes
>> use same device pins as in UART mode. So, you either can use the
>> device in UART interface mode or in some different mode. I do not
>> load the ftdi_sio module or do unbind the USB device from the
>> ftdio_sio driver and bind it to the mfd driver, e.g.:
>>
>> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
>> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"
>
>I'm afraid that's not good enough. If we're going to support a non-UART
>mode through a separate driver, we need to have all drivers for these
>devices be able to retrieve the current mode during probe and only bind
>when the mode matches.
Can we reliably retrieve the current mode? For devices with connected
EEPROM some modes (including UART) are configurable in the EEPROM. For
devices without EEPROM the default mode is always UART, but FIFO-,
Bitbang- and MPSSE-mode can be switched via commands to the the chip.
Anatolij
--
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: CPU lock-ups with 4.12.0+ kernels related to usb_storage
What else is plugged in? The top line of the log snippet you sent shows an error from a USB video device... I wonder if the error occurred in a different part of the stack, and it just finally bombs-out in usb-storage Matt On Mon, Jul 10, 2017 at 11:00 PM, Arthur Marsh wrote: > I've had several lock-ups on recent 4.12.0+ kernels that I've built. > > The machine has an Asus M3A78 Pro motherboard and 4-core AMD CPU. > > The only usb-storage in use is an external Seagate HDD with one ntfs-3g > filesystem and another ext3 filesystem mounted. > > A recent kernel log showed: > > Jul 11 06:43:06 localhost kernel: [ 7843.760926] usb 2-1: dvb_usb_v2: > rc.query() failed=-110 > Jul 11 06:43:26 localhost kernel: [ 7852.721052] NMI watchdog: Watchdog > detected hard LOCKUP on cpu 1 > Jul 11 06:43:26 localhost kernel: [ 7852.721054] Modules linked in: arc4 ecb > md4 nls_utf8 cifs ccm dns_resolver fscache bnep bluetooth hmac drbg > ansi_cprng ecdh_generic nfc rfkill cpufreq_userspace cpufreq_conservative > snd_hrtimer cpufreq_powersave binfmt_misc fuse snd_emu10k1_synth > snd_emux_synth snd_seq_midi_emul snd_seq_virmidi snd_seq_midi_event snd_seq > max6650 ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp > libiscsi scsi_transport_iscsi parport_pc ppdev lp parport snd_hda_codec_hdmi > ir_lirc_codec lirc_dev rtl2832_sdr videobuf2_vmalloc videobuf2_memops > videobuf2_v4l2 videobuf2_core videodev media fc0012 rtl2832 i2c_mux > dvb_usb_rtl28xxu dvb_usb_v2 dvb_core rc_core edac_mce_amd amdkfd kvm_amd > snd_emu10k1 snd_hda_intel kvm radeon snd_hda_codec irqbypass snd_util_mem > wmi_bmof snd_ac97_codec snd_hda_core ttm snd_rawmidi > Jul 11 06:43:26 localhost kernel: [ 7852.721080] snd_hwdep snd_seq_device > drm_kms_helper snd_pcm_oss ac97_bus k10temp snd_mixer_oss snd_pcm evdev > pcspkr emu10k1_gp gameport serio_raw snd_timer snd drm i2c_algo_bit > soundcore wmi sg asus_atk0110 sp5100_tco button acpi_cpufreq ext4 mbcache > crc16 jbd2 crc32c_generic btrfs raid6_pq xor uas usb_storage sr_mod cdrom > sd_mod hid_generic usbhid hid ata_generic ohci_pci ahci firewire_ohci > pata_atiixp libahci ehci_pci ohci_hcd firewire_core crc_itu_t ehci_hcd > i2c_piix4 libata scsi_mod usbcore r8169 mii > Jul 11 06:43:26 localhost kernel: [ 7852.721102] CPU: 1 PID: 145 Comm: > usb-storage Not tainted 4.12.0+ #2747 > Jul 11 06:43:26 localhost kernel: [ 7852.721103] Hardware name: System > manufacturer System Product Name/M3A78 PRO, BIOS 170101/27/2011 > Jul 11 06:43:26 localhost kernel: [ 7852.721104] task: 94e66139af80 > task.stack: b31d81b84000 > Jul 11 06:43:26 localhost kernel: [ 7852.721108] RIP: > 0010:native_queued_spin_lock_slowpath+0x153/0x1b0 > Jul 11 06:43:26 localhost kernel: [ 7852.721109] RSP: 0018:b31d81b87e50 > EFLAGS: 0002 > Jul 11 06:43:26 localhost kernel: [ 7852.721110] RAX: 0101 RBX: > 94e66132b030 RCX: 0001 > Jul 11 06:43:26 localhost kernel: [ 7852.72] RDX: 0101 RSI: > 0001 RDI: 94e66132b030 > Jul 11 06:43:26 localhost kernel: [ 7852.72] RBP: 0082 R08: > 0101 R09: 0100 > Jul 11 06:43:26 localhost kernel: [ 7852.721112] R10: R11: > 21219003 R12: 0001 > Jul 11 06:43:26 localhost kernel: [ 7852.721112] R13: 94e66139af80 R14: > 94e66132b7c0 R15: c018e5a0 > Jul 11 06:43:26 localhost kernel: [ 7852.721113] FS: () > GS:94e66fc4() knlGS: > Jul 11 06:43:26 localhost kernel: [ 7852.721114] CS: 0010 DS: ES: > CR0: 80050033 > Jul 11 06:43:26 localhost kernel: [ 7852.721115] CR2: 7f8e987dd000 CR3: > 000158bcb000 CR4: 06e0 > Jul 11 06:43:26 localhost kernel: [ 7852.721116] Call Trace: > Jul 11 06:43:26 localhost kernel: [ 7852.721119] ? > _raw_spin_lock_irqsave+0x5a/0x5e > Jul 11 06:43:26 localhost kernel: [ 7852.721130] ? > scsi_eh_scmd_add+0x44/0x150 [scsi_mod] > Jul 11 06:43:26 localhost kernel: [ 7852.721133] ? > fill_inquiry_response+0x20/0x20 [usb_storage] > Jul 11 06:43:26 localhost kernel: [ 7852.721135] ? > __blk_mq_complete_request+0xd7/0x170 > Jul 11 06:43:26 localhost kernel: [ 7852.721137] ? > usb_stor_control_thread+0xf0/0x250 [usb_storage] > Jul 11 06:43:26 localhost kernel: [ 7852.721139] ? > fill_inquiry_response+0x20/0x20 [usb_storage] > Jul 11 06:43:26 localhost kernel: [ 7852.721141] ? kthread+0x118/0x130 > Jul 11 06:43:26 localhost kernel: [ 7852.721143] ? > kthread_create_on_node+0x70/0x70 > Jul 11 06:43:26 localhost kernel: [ 7852.721144] ? ret_from_fork+0x25/0x30 > Jul 11 06:48:41 localhost kernel: [ 8178.540464] ? > fill_inquiry_response+0x20/0x20 [usb_storage] > Jul 11 06:48:41 localhost kernel: [ 8178.540466] ? > __blk_mq_complete_request+0xd7/0x170 > Jul 11 06:48:41 localhost kernel: [ 8178.540467] ? > usb_stor_control_thread+0xf0/0x250 [usb_storage] > Jul 11 06:48:41 localhost kernel: [ 8178.540469] ? > fill_inquiry_
CPU lock-ups with 4.12.0+ kernels related to usb_storage
I've had several lock-ups on recent 4.12.0+ kernels that I've built. The machine has an Asus M3A78 Pro motherboard and 4-core AMD CPU. The only usb-storage in use is an external Seagate HDD with one ntfs-3g filesystem and another ext3 filesystem mounted. A recent kernel log showed: Jul 11 06:43:06 localhost kernel: [ 7843.760926] usb 2-1: dvb_usb_v2: rc.query() failed=-110 Jul 11 06:43:26 localhost kernel: [ 7852.721052] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 Jul 11 06:43:26 localhost kernel: [ 7852.721054] Modules linked in: arc4 ecb md4 nls_utf8 cifs ccm dns_resolver fscache bnep bluetooth hmac drbg ansi_cprng ecdh_generic nfc rfkill cpufreq_userspace cpufreq_conservative snd_hrtimer cpufreq_powersave binfmt_misc fuse snd_emu10k1_synth snd_emux_synth snd_seq_midi_emul snd_seq_virmidi snd_seq_midi_event snd_seq max6650 ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi parport_pc ppdev lp parport snd_hda_codec_hdmi ir_lirc_codec lirc_dev rtl2832_sdr videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media fc0012 rtl2832 i2c_mux dvb_usb_rtl28xxu dvb_usb_v2 dvb_core rc_core edac_mce_amd amdkfd kvm_amd snd_emu10k1 snd_hda_intel kvm radeon snd_hda_codec irqbypass snd_util_mem wmi_bmof snd_ac97_codec snd_hda_core ttm snd_rawmidi Jul 11 06:43:26 localhost kernel: [ 7852.721080] snd_hwdep snd_seq_device drm_kms_helper snd_pcm_oss ac97_bus k10temp snd_mixer_oss snd_pcm evdev pcspkr emu10k1_gp gameport serio_raw snd_timer snd drm i2c_algo_bit soundcore wmi sg asus_atk0110 sp5100_tco button acpi_cpufreq ext4 mbcache crc16 jbd2 crc32c_generic btrfs raid6_pq xor uas usb_storage sr_mod cdrom sd_mod hid_generic usbhid hid ata_generic ohci_pci ahci firewire_ohci pata_atiixp libahci ehci_pci ohci_hcd firewire_core crc_itu_t ehci_hcd i2c_piix4 libata scsi_mod usbcore r8169 mii Jul 11 06:43:26 localhost kernel: [ 7852.721102] CPU: 1 PID: 145 Comm: usb-storage Not tainted 4.12.0+ #2747 Jul 11 06:43:26 localhost kernel: [ 7852.721103] Hardware name: System manufacturer System Product Name/M3A78 PRO, BIOS 170101/27/2011 Jul 11 06:43:26 localhost kernel: [ 7852.721104] task: 94e66139af80 task.stack: b31d81b84000 Jul 11 06:43:26 localhost kernel: [ 7852.721108] RIP: 0010:native_queued_spin_lock_slowpath+0x153/0x1b0 Jul 11 06:43:26 localhost kernel: [ 7852.721109] RSP: 0018:b31d81b87e50 EFLAGS: 0002 Jul 11 06:43:26 localhost kernel: [ 7852.721110] RAX: 0101 RBX: 94e66132b030 RCX: 0001 Jul 11 06:43:26 localhost kernel: [ 7852.72] RDX: 0101 RSI: 0001 RDI: 94e66132b030 Jul 11 06:43:26 localhost kernel: [ 7852.72] RBP: 0082 R08: 0101 R09: 0100 Jul 11 06:43:26 localhost kernel: [ 7852.721112] R10: R11: 21219003 R12: 0001 Jul 11 06:43:26 localhost kernel: [ 7852.721112] R13: 94e66139af80 R14: 94e66132b7c0 R15: c018e5a0 Jul 11 06:43:26 localhost kernel: [ 7852.721113] FS: () GS:94e66fc4() knlGS: Jul 11 06:43:26 localhost kernel: [ 7852.721114] CS: 0010 DS: ES: CR0: 80050033 Jul 11 06:43:26 localhost kernel: [ 7852.721115] CR2: 7f8e987dd000 CR3: 000158bcb000 CR4: 06e0 Jul 11 06:43:26 localhost kernel: [ 7852.721116] Call Trace: Jul 11 06:43:26 localhost kernel: [ 7852.721119] ? _raw_spin_lock_irqsave+0x5a/0x5e Jul 11 06:43:26 localhost kernel: [ 7852.721130] ? scsi_eh_scmd_add+0x44/0x150 [scsi_mod] Jul 11 06:43:26 localhost kernel: [ 7852.721133] ? fill_inquiry_response+0x20/0x20 [usb_storage] Jul 11 06:43:26 localhost kernel: [ 7852.721135] ? __blk_mq_complete_request+0xd7/0x170 Jul 11 06:43:26 localhost kernel: [ 7852.721137] ? usb_stor_control_thread+0xf0/0x250 [usb_storage] Jul 11 06:43:26 localhost kernel: [ 7852.721139] ? fill_inquiry_response+0x20/0x20 [usb_storage] Jul 11 06:43:26 localhost kernel: [ 7852.721141] ? kthread+0x118/0x130 Jul 11 06:43:26 localhost kernel: [ 7852.721143] ? kthread_create_on_node+0x70/0x70 Jul 11 06:43:26 localhost kernel: [ 7852.721144] ? ret_from_fork+0x25/0x30 Jul 11 06:48:41 localhost kernel: [ 8178.540464] ? fill_inquiry_response+0x20/0x20 [usb_storage] Jul 11 06:48:41 localhost kernel: [ 8178.540466] ? __blk_mq_complete_request+0xd7/0x170 Jul 11 06:48:41 localhost kernel: [ 8178.540467] ? usb_stor_control_thread+0xf0/0x250 [usb_storage] Jul 11 06:48:41 localhost kernel: [ 8178.540469] ? fill_inquiry_response+0x20/0x20 [usb_storage] Jul 11 06:48:41 localhost kernel: [ 8178.540470] ? kthread+0x118/0x130 Jul 11 06:48:41 localhost kernel: [ 8178.540472] ? kthread_create_on_node+0x70/0x70 Jul 11 06:48:41 localhost kernel: [ 8178.540473] ? ret_from_fork+0x25/0x30 Jul 11 06:48:41 localhost kernel: [ 8178.540473] Code: 39 c2 74 a5 89 c2 89 d0 66 31 c0 41 39 c0 74 ea 4d 85 c9 c6 07 01 74 21 4
Re: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]
On Mon, Jul 10, 2017 at 11:09 PM, Alan Robertson wrote: > On Mon, Jul 10, 2017 at 5:43 PM, Alan Robertson > wrote: >> On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern >> wrote: >>> On Mon, 10 Jul 2017, Alan Robertson wrote: >>> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson wrote: > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern > wrote: >> On Sat, 8 Jul 2017, Alan Robertson wrote: >> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern >>> wrote: >>> > On Fri, 7 Jul 2017, Alan Robertson wrote: >>> > >>> >> Sorry to return to this topic & appreciate it might be either >>> >> specific >>> >> to either the Pi or the system(s) I'm connecting it to, but have now >>> >> had time to try a few more combinations out and would appreciate any >>> >> thoughts from the experts here. >>> >> >>> >> To give some extra background - I've got the Pi configured to >>> >> automatically overwrite the mass storage device filestore upon boot, >>> >> so it is always presenting a fresh filesystem. Each system below is >>> >> made by a different manufacturer and is a closed system, so I have >>> >> no >>> >> ability to perform any diagnostics at that end. >>> >> >>> >> System 1 - Always works >>> >> System 2 - Shows no USB stick connected >>> >> System 3 - Gives error when trying to save (memory error) >>> >> System 4 - Says unidentified USB >>> >> (Windows PC - Always works) >>> >> (Linux PC - Always works) >>> >> >>> >> At first I thought this was due to minor subtleties of how the >>> >> g_mass_storage device was being presented as a standard Sandisk USB >>> >> memory stick works fine in all systems. >>> >> >>> >> However I then started to notice some unusual behaviour, if rather >>> >> than doing a reboot (and wiping it fresh), I kept the power running >>> >> and moved it between machines. >>> >> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all >>> >> recognise/write to it OK. >>> >>> ... >>> OK I've had another play about with things this afternoon and annotated the dmesg outputs to describe what I was doing at each point. I haven't yet tried to recompile the kernel as that seems a slightly slow process on the Pi (due to processing speed) and it make take me a few goes to get it right - I thought I'd just check back initially in case these logs provide sufficient clues! Obviously if not then I'll look into that more. The key bit to my untrained eye seemed to be that until the line 'g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage' appears, the Pi is unreadable by Systems 2-4. After that has appeared in then appears to be readable, even though when connecting to System 2 it (understandably and correctly) shows as low-speed instead. Stop/start g_mass_storage doesn't appear to make a difference. >>> >>> I agree. In fact, your logs seem to indicate pretty clearly that the >>> problem doesn't lie in g_mass_storage at all, but rather in the dwc2 >>> USB Device Controller driver. I have CC'ed the maintainer of the dwc2 >>> driver. >>> >>> Here's the first log: >>> [ 15.891896] Mass Storage Function, version: 2009/09/11 [ 15.891929] LUN: removable file: (no medium) [ 15.892120] LUN: removable file: /home/pi/piusb.bin [ 15.892135] Number of LUNs=1 [ 15.894168] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 15.894200] g_mass_storage gadget: g_mass_storage ready [ 15.894245] dwc2 2098.usb: dwc2_hsotg_enqueue_setup: failed queue (-11) [ 15.897276] dwc2 2098.usb: bound driver g_mass_storage CONNECTED TO SYSTEM 2 [ 263.798965] dwc2 2098.usb: new device is low-speed [ 269.497623] dwc2 2098.usb: new device is low-speed [ 275.115548] dwc2 2098.usb: new device is low-speed STILL NOT SHOWING UP ON SYSTEM 2 SO UNPLUGGED (no extra message) >>> >>> Connecting at low speed is definitely a bug. The UDC driver should >>> have connected at full speed. (It's possible that the log message is >>> wrong, and the device really did connect at full speed. But if that >>> were so, more log messages would have shown up.) >>> NOW PLUGGED IN TO WINDOWS 10 LAPTOP (after a second, file browser opened showing root folder of memory storage) [ 446.454380] dwc2 2098.usb: new device is high-speed [ 452.045884] dwc2 2098.usb: new device is high-speed [ 452.204357] dwc2 2098.usb: new device is high-speed [ 452.305171] dwc2 2098.usb: new address 7 [ 452.402701] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage >>> >>> High speed would also be correct. I assume that your System 2 doesn't >>> support high speed, however. >>
Re: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]
On Mon, Jul 10, 2017 at 5:43 PM, Alan Robertson wrote: > On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern wrote: >> On Mon, 10 Jul 2017, Alan Robertson wrote: >> >>> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson >>> wrote: >>> > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern >>> > wrote: >>> >> On Sat, 8 Jul 2017, Alan Robertson wrote: >>> >> >>> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern >>> >>> wrote: >>> >>> > On Fri, 7 Jul 2017, Alan Robertson wrote: >>> >>> > >>> >>> >> Sorry to return to this topic & appreciate it might be either >>> >>> >> specific >>> >>> >> to either the Pi or the system(s) I'm connecting it to, but have now >>> >>> >> had time to try a few more combinations out and would appreciate any >>> >>> >> thoughts from the experts here. >>> >>> >> >>> >>> >> To give some extra background - I've got the Pi configured to >>> >>> >> automatically overwrite the mass storage device filestore upon boot, >>> >>> >> so it is always presenting a fresh filesystem. Each system below is >>> >>> >> made by a different manufacturer and is a closed system, so I have no >>> >>> >> ability to perform any diagnostics at that end. >>> >>> >> >>> >>> >> System 1 - Always works >>> >>> >> System 2 - Shows no USB stick connected >>> >>> >> System 3 - Gives error when trying to save (memory error) >>> >>> >> System 4 - Says unidentified USB >>> >>> >> (Windows PC - Always works) >>> >>> >> (Linux PC - Always works) >>> >>> >> >>> >>> >> At first I thought this was due to minor subtleties of how the >>> >>> >> g_mass_storage device was being presented as a standard Sandisk USB >>> >>> >> memory stick works fine in all systems. >>> >>> >> >>> >>> >> However I then started to notice some unusual behaviour, if rather >>> >>> >> than doing a reboot (and wiping it fresh), I kept the power running >>> >>> >> and moved it between machines. >>> >>> >> >>> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all >>> >>> >> recognise/write to it OK. >> >> ... >> >>> OK I've had another play about with things this afternoon and >>> annotated the dmesg outputs to describe what I was doing at each >>> point. >>> >>> I haven't yet tried to recompile the kernel as that seems a slightly >>> slow process on the Pi (due to processing speed) and it make take me a >>> few goes to get it right - I thought I'd just check back initially in >>> case these logs provide sufficient clues! Obviously if not then I'll >>> look into that more. >>> >>> The key bit to my untrained eye seemed to be that until the line >>> 'g_mass_storage gadget: high-speed config #1: Linux File-Backed >>> Storage' appears, the Pi is unreadable by Systems 2-4. After that has >>> appeared in then appears to be readable, even though when connecting >>> to System 2 it (understandably and correctly) shows as low-speed >>> instead. Stop/start g_mass_storage doesn't appear to make a >>> difference. >> >> I agree. In fact, your logs seem to indicate pretty clearly that the >> problem doesn't lie in g_mass_storage at all, but rather in the dwc2 >> USB Device Controller driver. I have CC'ed the maintainer of the dwc2 >> driver. >> >> Here's the first log: >> >>> [ 15.891896] Mass Storage Function, version: 2009/09/11 >>> [ 15.891929] LUN: removable file: (no medium) >>> [ 15.892120] LUN: removable file: /home/pi/piusb.bin >>> [ 15.892135] Number of LUNs=1 >>> [ 15.894168] g_mass_storage gadget: Mass Storage Gadget, version: >>> 2009/09/11 >>> [ 15.894200] g_mass_storage gadget: g_mass_storage ready >>> [ 15.894245] dwc2 2098.usb: dwc2_hsotg_enqueue_setup: failed queue >>> (-11) >>> [ 15.897276] dwc2 2098.usb: bound driver g_mass_storage >>> CONNECTED TO SYSTEM 2 >>> [ 263.798965] dwc2 2098.usb: new device is low-speed >>> [ 269.497623] dwc2 2098.usb: new device is low-speed >>> [ 275.115548] dwc2 2098.usb: new device is low-speed >>> STILL NOT SHOWING UP ON SYSTEM 2 SO UNPLUGGED >>> (no extra message) >> >> Connecting at low speed is definitely a bug. The UDC driver should >> have connected at full speed. (It's possible that the log message is >> wrong, and the device really did connect at full speed. But if that >> were so, more log messages would have shown up.) >> >>> NOW PLUGGED IN TO WINDOWS 10 LAPTOP >>> (after a second, file browser opened showing root folder of memory storage) >>> [ 446.454380] dwc2 2098.usb: new device is high-speed >>> [ 452.045884] dwc2 2098.usb: new device is high-speed >>> [ 452.204357] dwc2 2098.usb: new device is high-speed >>> [ 452.305171] dwc2 2098.usb: new address 7 >>> [ 452.402701] g_mass_storage gadget: high-speed config #1: Linux >>> File-Backed Storage >> >> High speed would also be correct. I assume that your System 2 doesn't >> support high speed, however. > > Yes, I wouldn't be surprised if that is the case - I think they're at > least 12 years old and imagine they were slow to implement new > developments. > >>> DISCONNECTED AND RECONNE
RE: [PATCH v5] xhci: Bad Ethernet performance plugged in ASM1042A host
> -Original Message- > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com] > Sent: Monday, July 10, 2017 3:57 PM > To: Limonciello, Mario > Cc: Mathias Nyman ; USB u...@vger.kernel.org>; mathias.ny...@intel.com; david.lai...@aculab.com; > Greg Kroah-Hartman ; Felipe Balbi > ; brain_...@asmedia.com.tw; > justin_cy_c...@asmedia.com.tw; Wang, Keith ; > yd_ts...@asmedia.com.tw; lars_ch...@asmedia.com.tw; > arequip...@gmail.com; jia...@gmail.com > Subject: Re: [PATCH v5] xhci: Bad Ethernet performance plugged in ASM1042A > host > > On Mon, Jul 10, 2017 at 11:38 PM, wrote: > >> -Original Message- > >> From: Jiahau Chang [mailto:jia...@gmail.com] > >> Sent: Thursday, July 6, 2017 8:58 PM > >> To: Mathias Nyman > >> Cc: linux-usb@vger.kernel.org; mathias.ny...@intel.com; > >> david.lai...@aculab.com; gre...@linuxfoundation.org; > >> felipe.ba...@linux.intel.com; brain_...@asmedia.com.tw; Limonciello, Mario > >> ; justin_cy_c...@asmedia.com.tw; Wang, > Keith > >> ; yd_ts...@asmedia.com.tw; Jiahau Chang > >> ; Ian Pilcher > >> Subject: Re: [PATCH v5] xhci: Bad Ethernet performance plugged in ASM1042A > host > >> > >> 2017-06-28 21:42 GMT+08:00 Mathias Nyman > : > >> > On 22.06.2017 07:49, Jiahau Chang wrote: > >> >> > >> >> When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad > >> >> performance was manifesting in Web browser use (like download > >> >> large file such as ISO image). It is known limitation of > >> >> ASM1042A that is not compatible with driver scheduling, > >> >> As a workaround we can modify flow control handling of ASM1042A. > >> >> The register we modify is changes the behavior > >> >> > >> >> Signed-off-by: Jiahau Chang > >> >> Signed-off-by: Ian Pilcher > >> >> --- > >> > > >> > > >> > Thanks, looks good, but checkpatch complains about: > >> > > >> >> + usleep_range(50, 50); > >> > > >> > > >> > having same min and max value. > >> > Does usleep_range(40,60) work for you? or some other range? > >> > > >> It works to use usleep_range(40,60); > >> Thanks for help us to upstream the patch. > >> > >> > I can change that myself, no need to resend. > >> > > > > > Matthias, > > > > Can you still get this in for 4.13? > > He is on vacation for few weeks. > > Perhaps in rcX. > > Thanks for the heads up, I wasn't aware since I didn't get back any OOO or anything like that. I hope this can make it into one of the rc's indeed then when he returns. Thanks
Re: [PATCH v5] xhci: Bad Ethernet performance plugged in ASM1042A host
On Mon, Jul 10, 2017 at 11:38 PM, wrote: >> -Original Message- >> From: Jiahau Chang [mailto:jia...@gmail.com] >> Sent: Thursday, July 6, 2017 8:58 PM >> To: Mathias Nyman >> Cc: linux-usb@vger.kernel.org; mathias.ny...@intel.com; >> david.lai...@aculab.com; gre...@linuxfoundation.org; >> felipe.ba...@linux.intel.com; brain_...@asmedia.com.tw; Limonciello, Mario >> ; justin_cy_c...@asmedia.com.tw; Wang, Keith >> ; yd_ts...@asmedia.com.tw; Jiahau Chang >> ; Ian Pilcher >> Subject: Re: [PATCH v5] xhci: Bad Ethernet performance plugged in ASM1042A >> host >> >> 2017-06-28 21:42 GMT+08:00 Mathias Nyman : >> > On 22.06.2017 07:49, Jiahau Chang wrote: >> >> >> >> When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad >> >> performance was manifesting in Web browser use (like download >> >> large file such as ISO image). It is known limitation of >> >> ASM1042A that is not compatible with driver scheduling, >> >> As a workaround we can modify flow control handling of ASM1042A. >> >> The register we modify is changes the behavior >> >> >> >> Signed-off-by: Jiahau Chang >> >> Signed-off-by: Ian Pilcher >> >> --- >> > >> > >> > Thanks, looks good, but checkpatch complains about: >> > >> >> + usleep_range(50, 50); >> > >> > >> > having same min and max value. >> > Does usleep_range(40,60) work for you? or some other range? >> > >> It works to use usleep_range(40,60); >> Thanks for help us to upstream the patch. >> >> > I can change that myself, no need to resend. >> > > > Matthias, > > Can you still get this in for 4.13? He is on vacation for few weeks. Perhaps in rcX. -- With Best Regards, Andy Shevchenko -- 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 v5] xhci: Bad Ethernet performance plugged in ASM1042A host
> -Original Message- > From: Jiahau Chang [mailto:jia...@gmail.com] > Sent: Thursday, July 6, 2017 8:58 PM > To: Mathias Nyman > Cc: linux-usb@vger.kernel.org; mathias.ny...@intel.com; > david.lai...@aculab.com; gre...@linuxfoundation.org; > felipe.ba...@linux.intel.com; brain_...@asmedia.com.tw; Limonciello, Mario > ; justin_cy_c...@asmedia.com.tw; Wang, Keith > ; yd_ts...@asmedia.com.tw; Jiahau Chang > ; Ian Pilcher > Subject: Re: [PATCH v5] xhci: Bad Ethernet performance plugged in ASM1042A > host > > 2017-06-28 21:42 GMT+08:00 Mathias Nyman : > > On 22.06.2017 07:49, Jiahau Chang wrote: > >> > >> When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad > >> performance was manifesting in Web browser use (like download > >> large file such as ISO image). It is known limitation of > >> ASM1042A that is not compatible with driver scheduling, > >> As a workaround we can modify flow control handling of ASM1042A. > >> The register we modify is changes the behavior > >> > >> Signed-off-by: Jiahau Chang > >> Signed-off-by: Ian Pilcher > >> --- > > > > > > Thanks, looks good, but checkpatch complains about: > > > >> + usleep_range(50, 50); > > > > > > having same min and max value. > > Does usleep_range(40,60) work for you? or some other range? > > > It works to use usleep_range(40,60); > Thanks for help us to upstream the patch. > > > I can change that myself, no need to resend. > > Matthias, Can you still get this in for 4.13? Thanks,
Re: JMS567 USB3.0 scsi scan error
On Mon, 10 Jul 2017, Oliver Neukum wrote: > > > The old storage driver unconditionally limits inquiries to 36 bytes. UAS > > > does not > > > have that limit. That seems to be a bit optimistic. Could you test the > > > attached patch? > > > > If there's no particular benefit to 96-byte inquiries, it would be > > Interesting. Why do we make them at all? I don't know. Presumably they do provide useful information for some devices, but I'm not aware of what that information is -- you'd have to ask the SCSI people. What I really had in mind was whether a 96-byte inquiry provides any benefit for USB mass-storage devices. Again, I don't know the answer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: isp1760: compress return logic into one line
Hi Oliver, Quoting Oliver Neukum : Am Sonntag, den 09.07.2017, 21:00 -0500 schrieb Gustavo A. R. Silva : Simplify return logic to avoid unnecessary variable assignment. This issue was detected using Coccinelle and the following semantic patch: Hi, I need to ask: Where is the improvement? The compiler does not bother and for the human reader you do not do anything obvious and you decreased grepability. The declaration of local variable _retval_ was removed also. So both, variable declaration and assignment removal are the improvements. Regarding the greability, I think that depends on the context. Thanks! -- Gustavo A. R. Silva -- 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: JMS567 USB3.0 scsi scan error
Am Montag, den 10.07.2017, 10:30 -0400 schrieb Alan Stern: > On Mon, 10 Jul 2017, Oliver Neukum wrote: > > > Am Donnerstag, den 06.07.2017, 14:32 -0700 schrieb Grégoire Gentil : > > > > Hi, > > > > > This might be a follow-up of: > > > https://www.spinics.net/lists/linux-usb/msg157437.html > > > https://www.spinics.net/lists/linux-usb/msg153647.html > > > > It does not look like that. > > > > > I have bought this adapter: > > > http://www.ebay.com/itm/122523342593 > > > > > > > > > The chip has the following marking: > > > JM JMS567 > > > http://www.jmicron.com/PDF/brief/jms567.pdf > > > > > > > > > My laptop is running: > > > Linux yoga 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57 > > > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > > > > > > LSB Version: > > > core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch > > > Distributor ID: Ubuntu > > > Description:Ubuntu 16.04.2 LTS > > > Release:16.04 > > > Codename: xenial > > > > > > > > > When I plug the device, I get the following error message: > > > [ 1503.223516] usb 1-7: new high-speed USB device number 10 using xhci_hcd > > > [ 1503.444964] usb 1-7: New USB device found, idVendor=152d, > > > idProduct=0539 > > > [ 1503.444970] usb 1-7: New USB device strings: Mfr=1, Product=2, > > > SerialNumber=3 > > > [ 1503.444973] usb 1-7: Product: USB to ATA/ATAPI Bridge > > > [ 1503.444976] usb 1-7: Manufacturer: JMicron > > > [ 1503.444979] usb 1-7: SerialNumber: 00A12345789F > > > [ 1503.447024] scsi host1: uas > > > [ 1511.457666] scsi 1:0:0:0: scsi scan: 96 byte inquiry failed. Consider > > > BLIST_INQUIRY_36 for this device > > > > > > > > > The device is working on Windows 10. > > > > > > > > > Any idea what could be the problem? > > > > The old storage driver unconditionally limits inquiries to 36 bytes. UAS > > does not > > have that limit. That seems to be a bit optimistic. Could you test the > > attached patch? > > If there's no particular benefit to 96-byte inquiries, it would be Interesting. Why do we make them at all? > better to apply this limit unconditionally than to make a quirk for it. > (Not to mention that your proposed patch has a copy & paste error -- > the quirk number wasn't incremented.) > > Besides, we're running out of bits for quirks. Only a few more will > require expanding it to a 64-bit field. > Valid points. Grégoire, please test the patch anyway. It will show the cause of the problem. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips
On 10 July 2017 at 16:52, Marc Zyngier wrote:
> Ard and myself have just spent quite some time lately trying to pin
> down an issue in the DMA code which was taking the form of a PCIe USB3
> controller issuing a DMA access at some bizarre address, and being
> caught red-handed by the IOMMU.
>
> After much head scratching and most of a week-end spent on tracing the
> damn thing, I'm now convinced that the DMA code is fine, the XHCI
> driver is correct, but that the HW (a Renesas uPD720202 chip) is a
> nasty piece of work.
>
> The issue is as follow:
>
> - EFI initializes the controller using physical addresses above the
> 4GB limit (this is on an arm64 box where the memory starts at
> 0x80_...).
>
> - The kernel takes over, sends a XHCI reset to the controller, and
> because we have an IOMMU sitting between the controller and memory,
> provides *virtual* addresses. Trying to make things a bit faster for
> our controller, it issues IOVAs in the low 4GB range).
>
> - Low and behold, the controller is now issuing transactions with a
> 0x80 prefix in front of our IOVA. Yes, the same prefix that was
> programmed during the EFI configuration. IOMMU fault, not happy.
>
> If the kernel is hacked to only generate IOVAs that are more than
> 32bit wide, the HW behaves correctly. The only way I can explain this
> behaviour is that the HW latches the top 32bit of the ERST (it is
> always the ERST IOVA that appears in my traces) in some internal
> register, and that the XHCI reset fails to clear it. Writing zero in
> the top bits is not enough to clear it either.
>
To clarify, this seems to be an issue in the internal DMA logic of the
controller. The ESRT base address register *is* cleared by the XHCI
reset, i.e., it reads back as all zeroes. However, any 32-bit value we
write there is extended with the high word written by the UEFI in the
actual DMA transactions that take place.
> So far, the only solution we have for this lovely piece of kit is to
> force a PCI reset at probe time, which puts it right. The patches are
> pretty ugly, but that's the best I could come up with so far.
>
> Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and
> uPD720202 controllers.
>
> Marc Zyngier (2):
> PCI: Implement pci_reset_function_locked
> usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB
> controller
>
> drivers/pci/pci.c | 35 +++
> drivers/usb/host/pci-quirks.c | 20
> drivers/usb/host/pci-quirks.h | 1 +
> drivers/usb/host/xhci-pci.c | 7 +++
> include/linux/pci.h | 1 +
> 5 files changed, 64 insertions(+)
>
This issue was uncovered by commit 122fac030e91 ("iommu/dma: Implement
PCI allocation optimisation"), which appeared in v4.11. So if this
approach is considered appropriate, it would be nice if we could tag
it for v4.11-stable as well.
Thanks,
Ard.
--
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: Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]
On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern wrote: > On Mon, 10 Jul 2017, Alan Robertson wrote: > >> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson >> wrote: >> > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern >> > wrote: >> >> On Sat, 8 Jul 2017, Alan Robertson wrote: >> >> >> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern >> >>> wrote: >> >>> > On Fri, 7 Jul 2017, Alan Robertson wrote: >> >>> > >> >>> >> Sorry to return to this topic & appreciate it might be either specific >> >>> >> to either the Pi or the system(s) I'm connecting it to, but have now >> >>> >> had time to try a few more combinations out and would appreciate any >> >>> >> thoughts from the experts here. >> >>> >> >> >>> >> To give some extra background - I've got the Pi configured to >> >>> >> automatically overwrite the mass storage device filestore upon boot, >> >>> >> so it is always presenting a fresh filesystem. Each system below is >> >>> >> made by a different manufacturer and is a closed system, so I have no >> >>> >> ability to perform any diagnostics at that end. >> >>> >> >> >>> >> System 1 - Always works >> >>> >> System 2 - Shows no USB stick connected >> >>> >> System 3 - Gives error when trying to save (memory error) >> >>> >> System 4 - Says unidentified USB >> >>> >> (Windows PC - Always works) >> >>> >> (Linux PC - Always works) >> >>> >> >> >>> >> At first I thought this was due to minor subtleties of how the >> >>> >> g_mass_storage device was being presented as a standard Sandisk USB >> >>> >> memory stick works fine in all systems. >> >>> >> >> >>> >> However I then started to notice some unusual behaviour, if rather >> >>> >> than doing a reboot (and wiping it fresh), I kept the power running >> >>> >> and moved it between machines. >> >>> >> >> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all >> >>> >> recognise/write to it OK. > > ... > >> OK I've had another play about with things this afternoon and >> annotated the dmesg outputs to describe what I was doing at each >> point. >> >> I haven't yet tried to recompile the kernel as that seems a slightly >> slow process on the Pi (due to processing speed) and it make take me a >> few goes to get it right - I thought I'd just check back initially in >> case these logs provide sufficient clues! Obviously if not then I'll >> look into that more. >> >> The key bit to my untrained eye seemed to be that until the line >> 'g_mass_storage gadget: high-speed config #1: Linux File-Backed >> Storage' appears, the Pi is unreadable by Systems 2-4. After that has >> appeared in then appears to be readable, even though when connecting >> to System 2 it (understandably and correctly) shows as low-speed >> instead. Stop/start g_mass_storage doesn't appear to make a >> difference. > > I agree. In fact, your logs seem to indicate pretty clearly that the > problem doesn't lie in g_mass_storage at all, but rather in the dwc2 > USB Device Controller driver. I have CC'ed the maintainer of the dwc2 > driver. > > Here's the first log: > >> [ 15.891896] Mass Storage Function, version: 2009/09/11 >> [ 15.891929] LUN: removable file: (no medium) >> [ 15.892120] LUN: removable file: /home/pi/piusb.bin >> [ 15.892135] Number of LUNs=1 >> [ 15.894168] g_mass_storage gadget: Mass Storage Gadget, version: >> 2009/09/11 >> [ 15.894200] g_mass_storage gadget: g_mass_storage ready >> [ 15.894245] dwc2 2098.usb: dwc2_hsotg_enqueue_setup: failed queue >> (-11) >> [ 15.897276] dwc2 2098.usb: bound driver g_mass_storage >> CONNECTED TO SYSTEM 2 >> [ 263.798965] dwc2 2098.usb: new device is low-speed >> [ 269.497623] dwc2 2098.usb: new device is low-speed >> [ 275.115548] dwc2 2098.usb: new device is low-speed >> STILL NOT SHOWING UP ON SYSTEM 2 SO UNPLUGGED >> (no extra message) > > Connecting at low speed is definitely a bug. The UDC driver should > have connected at full speed. (It's possible that the log message is > wrong, and the device really did connect at full speed. But if that > were so, more log messages would have shown up.) > >> NOW PLUGGED IN TO WINDOWS 10 LAPTOP >> (after a second, file browser opened showing root folder of memory storage) >> [ 446.454380] dwc2 2098.usb: new device is high-speed >> [ 452.045884] dwc2 2098.usb: new device is high-speed >> [ 452.204357] dwc2 2098.usb: new device is high-speed >> [ 452.305171] dwc2 2098.usb: new address 7 >> [ 452.402701] g_mass_storage gadget: high-speed config #1: Linux >> File-Backed Storage > > High speed would also be correct. I assume that your System 2 doesn't > support high speed, however. Yes, I wouldn't be surprised if that is the case - I think they're at least 12 years old and imagine they were slow to implement new developments. >> DISCONNECTED AND RECONNECTED TO SYSTEM 2 >> [ 522.097785] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:176 >> dwc2_hsotg_init_fifo+0x188/0x1a8 [dwc2]() >> [ 522.097802] Modules linked in: g_mass
[PATCH 0/2] Workaround for uPD72020x USB3 chips
Ard and myself have just spent quite some time lately trying to pin down an issue in the DMA code which was taking the form of a PCIe USB3 controller issuing a DMA access at some bizarre address, and being caught red-handed by the IOMMU. After much head scratching and most of a week-end spent on tracing the damn thing, I'm now convinced that the DMA code is fine, the XHCI driver is correct, but that the HW (a Renesas uPD720202 chip) is a nasty piece of work. The issue is as follow: - EFI initializes the controller using physical addresses above the 4GB limit (this is on an arm64 box where the memory starts at 0x80_...). - The kernel takes over, sends a XHCI reset to the controller, and because we have an IOMMU sitting between the controller and memory, provides *virtual* addresses. Trying to make things a bit faster for our controller, it issues IOVAs in the low 4GB range). - Low and behold, the controller is now issuing transactions with a 0x80 prefix in front of our IOVA. Yes, the same prefix that was programmed during the EFI configuration. IOMMU fault, not happy. If the kernel is hacked to only generate IOVAs that are more than 32bit wide, the HW behaves correctly. The only way I can explain this behaviour is that the HW latches the top 32bit of the ERST (it is always the ERST IOVA that appears in my traces) in some internal register, and that the XHCI reset fails to clear it. Writing zero in the top bits is not enough to clear it either. So far, the only solution we have for this lovely piece of kit is to force a PCI reset at probe time, which puts it right. The patches are pretty ugly, but that's the best I could come up with so far. Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and uPD720202 controllers. Marc Zyngier (2): PCI: Implement pci_reset_function_locked usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller drivers/pci/pci.c | 35 +++ drivers/usb/host/pci-quirks.c | 20 drivers/usb/host/pci-quirks.h | 1 + drivers/usb/host/xhci-pci.c | 7 +++ include/linux/pci.h | 1 + 5 files changed, 64 insertions(+) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] PCI: Implement pci_reset_function_locked
The implementation of PCI workarounds may require that the device
is reset from its probe function. This implies that the PCI device
lock is already held, and makes calling pci_reset_function impossible
(since it will itself try to take that lock).
This patch introduces pci_reset_function_locked, which is the equivalent
of pci_reset_function, except that it requires the PCI device lock to
be already held by the caller.
Signed-off-by: Marc Zyngier
---
drivers/pci/pci.c | 35 +++
include/linux/pci.h | 1 +
2 files changed, 36 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 563901cd9c06..a2c3e8b94f65 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -4287,6 +4287,41 @@ int pci_reset_function(struct pci_dev *dev)
EXPORT_SYMBOL_GPL(pci_reset_function);
/**
+ * pci_reset_function_locked - quiesce and reset a PCI device function
+ * @dev: PCI device to reset
+ *
+ * Some devices allow an individual function to be reset without affecting
+ * other functions in the same device. The PCI device must be responsive
+ * to PCI config space in order to use this function.
+ *
+ * This function does not just reset the PCI portion of a device, but
+ * clears all the state associated with the device. This function differs
+ * from __pci_reset_function in that it saves and restores device state
+ * over the reset. it also differs from pci_reset_function in that it
+ * requires the PCI device lock to be held.
+ *
+ * Returns 0 if the device function was successfully reset or negative if the
+ * device doesn't support resetting a single function.
+ */
+int pci_reset_function_locked(struct pci_dev *dev)
+{
+ int rc;
+
+ rc = pci_dev_reset(dev, 1);
+ if (rc)
+ return rc;
+
+ pci_dev_save_and_disable(dev);
+
+ rc = __pci_dev_reset(dev, 0);
+
+ pci_dev_restore(dev);
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(pci_reset_function_locked);
+
+/**
* pci_try_reset_function - quiesce and reset a PCI device function
* @dev: PCI device to reset
*
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f0ca05..16be18678ca1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1049,6 +1049,7 @@ void pcie_flr(struct pci_dev *dev);
int __pci_reset_function(struct pci_dev *dev);
int __pci_reset_function_locked(struct pci_dev *dev);
int pci_reset_function(struct pci_dev *dev);
+int pci_reset_function_locked(struct pci_dev *dev);
int pci_try_reset_function(struct pci_dev *dev);
int pci_probe_reset_slot(struct pci_slot *slot);
int pci_reset_slot(struct pci_slot *slot);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller
The Renesas uPD72020x XHCI controller seems to suffer from a
really annoying bug, where it may retain some of its DMA programming
across a XHCI reset, and despite the driver correctly programming new
DMA addresses. This is visible if the device has been using 64bit DMA
addresses, and is then switched to using 32bit DMA addresses. The top
32bits of the address (now zero) are ignored are replaced by the 32bit
from the *previous* programming. Sticking with 64bit DMA always works,
but doesn't seem very appropriate.
A PCI reset of the device restores the normal functionnality, which
is done at probe time. Unfortunately, this has to be done before
any quirk has been discovered, hence the intrusive nature of the fix.
Signed-off-by: Marc Zyngier
---
drivers/usb/host/pci-quirks.c | 20
drivers/usb/host/pci-quirks.h | 1 +
drivers/usb/host/xhci-pci.c | 7 +++
3 files changed, 28 insertions(+)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c40480..5bed002c7dd3 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -1096,3 +1096,23 @@ static void quirk_usb_early_handoff(struct pci_dev *pdev)
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_SERIAL_USB, 8, quirk_usb_early_handoff);
+
+bool usb_xhci_needs_pci_reset(struct pci_dev *pdev)
+{
+ /*
+* Our dear uPD72020{1,2} friend only partially resets when
+* asked to via the XHCI interface, and may end-up doing DMA
+* at the wrong addresses, as it keeps the top 32bit of some
+* addresses from its previous programming under obscure
+* circumstances.
+* Give it a good wack at probe time. Unfortunately, this
+* needs to happen before we've had a chance to discover any
+* quirk, or the system will be in a rather bad state.
+*/
+ if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
+ (pdev->device == 0x0014 || pdev->device == 0x0015))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(usb_xhci_needs_pci_reset);
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index 0222195bd5b0..dcbe4b097b33 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -14,6 +14,7 @@ void usb_amd_quirk_pll_enable(void);
void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev);
void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
void sb800_prefetch(struct device *dev, int on);
+bool usb_xhci_needs_pci_reset(struct pci_dev *pdev);
#else
struct pci_dev;
static inline void usb_amd_quirk_pll_disable(void) {}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1bcf971141c0..3831705c2817 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -267,6 +267,13 @@ static int xhci_pci_probe(struct pci_dev *dev, const
struct pci_device_id *id)
driver = (struct hc_driver *)id->driver_data;
+ /* For some HW implementation, a XHCI reset is just not enough... */
+ if (usb_xhci_needs_pci_reset(dev)) {
+ dev_info(&dev->dev, "Resetting\n");
+ if (pci_reset_function_locked(dev))
+ dev_warn(&dev->dev, "Reset failed");
+ }
+
/* Prevent runtime suspending between USB-2 and USB-3 initialization */
pm_runtime_get_noresume(&dev->dev);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
Hi Filipe, On 7/10/2017 6:14 PM, Felipe Balbi wrote: > > Hi again, > > Felipe Balbi writes: >> Hi, >> >> Minas Harutyunyan writes: >>> USB CV driver stack doesn't perform USB RESET after device disconnect/ >>> connect, so need to reset to zero DEVADDR field in DCFG to pass >>> enumeration again. >>> >>> Signed-off-by: Minas Harutyunyan >>> --- >>> drivers/usb/dwc2/gadget.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c >>> index 98a4a79e7f6e..deb3d901b99d 100644 >>> --- a/drivers/usb/dwc2/gadget.c >>> +++ b/drivers/usb/dwc2/gadget.c >>> @@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg) >>> return; >>> >>> hsotg->connected = 0; >>> + /* On disconnect reset device address to zero */ >>> + __bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK); >>> + >> >> Which of the tests are you talking about? Which particular USB CV are >> you running? >> >> I don't remember ever seeing this with dwc3. How should I go about >> triggering this problem? If this was really the case, then we would have >> this on *all* UDCs. >> >> I just did a fresh install of USB 3 Gen X CV (that I just download from >> usb.org). Ran Chapter 9 tests against a HS dwc3 board I have around and >> I can't see the problem you're talking about. >> >> Here are all my non-endpoint interrupt events in order. Test passes >> fine. If disconnect, reconnect and run the tests again, then Reset will >> be driven on the bus which will cause address to be reset. >> >> Can you share more details about the problem you're facing? > > I've been looking at dwc2 for a while and I think this is a bug in > dwc2_hsotg_irq() on the branch for GINTSTS_USBRST. I don't have docs for > dwc2. > USB RESET not issuing by CV host stack after connect. Below dmesg: Disconnect [23984.039199] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008428 0400 (d0bc3cc4) retry 8 [23984.039204] dwc2 dwc2.1.auto: GINTSTS_ErlySusp [23984.042235] dwc2 dwc2.1.auto: gintsts=04008828 gintmsk=d0bc3cc4 [23984.042240] dwc2 dwc2.1.auto: USB SUSPEND [23984.042247] dwc2 dwc2.1.auto: DSTS=0x5f4c01 [23984.042250] dwc2 dwc2.1.auto: DSTS.Suspend Status=1 HWCFG4.Power Optimize=0 [23984.042260] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008028 (d0bc3cc4) retry 8 [23984.272308] dwc2 dwc2.1.auto: gintsts=0480902c gintmsk=d0bc3cc4 [23984.272318] dwc2 dwc2.1.auto: ++OTG Interrupt gotgint=4 [b_peripheral] [23984.272321] dwc2 dwc2.1.auto: ++OTG Interrupt: Session End Detected++ (b_peripheral) [23984.272331] dwc2 dwc2.1.auto: complete: ep 880401a31b28 ep0, req 8803e495ef00, -108 => a00541da [23984.272336] dwc2 dwc2.1.auto: dwc2_hsotg_complete_setup: failed -108 [23984.272346] dwc2 dwc2.1.auto: complete: ep 880401a30328 ep1out, req 88040b6d7c80, -108 => a008865c [23984.272435] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04809028 00801000 (d0bc3cc4) retry 8 [23984.272437] dwc2 dwc2.1.auto: dwc2_hsotg_irq: USBRstDet [23984.272442] dwc2 dwc2.1.auto: dwc2_hsotg_irq: USBRst [23984.272446] dwc2 dwc2.1.auto: GNPTXSTS=00040300 [23984.272473] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable(ep 880401a30528) [23984.272478] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable: DxEPCTL=0x084a0200 [23984.272485] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable(ep 880401a30328) [23984.272490] dwc2 dwc2.1.auto: dwc2_hsotg_ep_stop_xfr: stopping transfer on ep1out [23984.272513] dwc2 dwc2.1.auto: dwc2_hsotg_ep_disable: DxEPCTL=0x08080200 [23984.272540] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008028 (d0bc3cc4) retry 8 Connect [24010.664017] dwc2 dwc2.1.auto: gintsts=44008028 gintmsk=d0bc3cc4 [24010.664023] dwc2 dwc2.1.auto: Session request interrupt - lx_state=0 [24010.664035] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04008028 (d0bc3cc4) retry 8 Run test First try to enumerate [24021.649528] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 0400a028 2000 (d0bc3cc4) retry 8 [24021.649536] dwc2 dwc2.1.auto: EnumDone (DSTS=0x0043e902) [24021.649539] dwc2 dwc2.1.auto: new device is full-speed [24021.649618] dwc2 dwc2.1.auto: dwc2_hsotg_enqueue_setup: queueing setup request [24021.649623] dwc2 dwc2.1.auto: ep0: req 8803e495ef00: 8@88040ad1d228, noi=0, zero=0, snok=0 [24021.649631] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DxEPCTL=0x80028000, ep 0, dir out [24021.649636] dwc2 dwc2.1.auto: ureq->length:8 ureq->actual:0 [24021.649640] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: 1@8/8, 0x00080008 => 0x0b10 [24021.649643] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: 0xd9858800 => 0x0b14 [24021.649645] dwc2 dwc2.1.auto: ep0 state:0 [24021.649648] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DxEPCTL=0x80028000 [24021.649654] dwc2 dwc2.1.auto: dwc2_hsotg_start_req: DXEPCTL=0x80028000 [24021.649664] dwc2 dwc2.1.auto: EP0: DIEPCTL0=0x8000, DOEPCTL0=0x80028000 [24021.849430] dwc2 dwc2.1.auto: dwc2_hsotg_irq: 04088028 0008 (d0bc3cc4) retry 8 [24021.849439] dwc2 dwc2.1.auto: dwc2_hsotg_irq: daint=00010
Re: [PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
Hi Filipe, On 7/10/2017 6:06 PM, Felipe Balbi wrote: > > Hi, > > Minas Harutyunyan writes: >> USB CV driver stack doesn't perform USB RESET after device disconnect/ >> connect, so need to reset to zero DEVADDR field in DCFG to pass >> enumeration again. >> >> Signed-off-by: Minas Harutyunyan >> --- >> drivers/usb/dwc2/gadget.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c >> index 98a4a79e7f6e..deb3d901b99d 100644 >> --- a/drivers/usb/dwc2/gadget.c >> +++ b/drivers/usb/dwc2/gadget.c >> @@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg) >> return; >> >> hsotg->connected = 0; >> +/* On disconnect reset device address to zero */ >> +__bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK); >> + > > Which of the tests are you talking about? Which particular USB CV are > you running? > I used USB 3 Gen X CV (downloaded from usb.org 1-2 week ago). Tests are: 1. "Device Summary" - after 1st pass, disconnect then connect again test failed. Actually it show as "test passed" but not able to enumerate device again. 2. MSC "USB Mass Storage Power Up Test". After disconnect, by suite request, and then connect test failed (pass, if reloading driver). > I don't remember ever seeing this with dwc3. How should I go about > triggering this problem? If this was really the case, then we would have > this on *all* UDCs. > dwc2 driver resetting DEVADDR in DCFG register only in function dwc2_hsotg_core_init_disconnected() by soft reset. This function not called on disconnect/connect with CV SW stack (function call not seen in dmesg). This issue not seen with any other EHCI/XHCI hosts either on Linux/Windows because these hosts issuing USB RESET, as result called dwc2_hsotg_core_init_disconnected(). In dwc3 per my understanding same stuff done in function dwc3_gadget_reset_interrupt(), am I right? > I just did a fresh install of USB 3 Gen X CV (that I just download from > usb.org). Ran Chapter 9 tests against a HS dwc3 board I have around and > I can't see the problem you're talking about. > Yes, this issue not seen with dwc3. > Here are all my non-endpoint interrupt events in order. Test passes > fine. If disconnect, reconnect and run the tests again, then Reset will > be driven on the bus which will cause address to be reset. > > Can you share more details about the problem you're facing? > > events > === > > irq/34-dwc3-1609 [001] d..1 13907.710095: dwc3_event: event (0001): > Disconnect: [U0] > irq/34-dwc3-1609 [001] d..1 13958.860840: dwc3_event: event (0001): > Disconnect: [U0] > irq/34-dwc3-1609 [001] d..1 14161.547651: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14161.602254: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14163.314174: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14163.368819: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14168.706773: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14168.758551: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14190.027840: dwc3_event: event (0401): > WakeUp [U0] > irq/34-dwc3-1609 [001] d..1 14203.428377: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14203.479869: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14203.739212: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14203.790550: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14204.025838: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14204.077335: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14204.329353: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14204.380840: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14204.629167: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14204.680503: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14204.941740: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14204.993141: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14205.233103: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14205.285111: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14205.543597: dwc3_event: event (0101): > Reset [U0] > irq/34-dwc3-1609 [001] d..1 14205.595033: dwc3_event: event (0201): > Connection Done [U0] > irq/34-dwc3-1609 [001] d..1 14205.840592: dwc3_event: event
Bug in DWC2 UDC driver on Raspberry PI [was: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID]
On Mon, 10 Jul 2017, Alan Robertson wrote: > On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson > wrote: > > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern > > wrote: > >> On Sat, 8 Jul 2017, Alan Robertson wrote: > >> > >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern > >>> wrote: > >>> > On Fri, 7 Jul 2017, Alan Robertson wrote: > >>> > > >>> >> Sorry to return to this topic & appreciate it might be either specific > >>> >> to either the Pi or the system(s) I'm connecting it to, but have now > >>> >> had time to try a few more combinations out and would appreciate any > >>> >> thoughts from the experts here. > >>> >> > >>> >> To give some extra background - I've got the Pi configured to > >>> >> automatically overwrite the mass storage device filestore upon boot, > >>> >> so it is always presenting a fresh filesystem. Each system below is > >>> >> made by a different manufacturer and is a closed system, so I have no > >>> >> ability to perform any diagnostics at that end. > >>> >> > >>> >> System 1 - Always works > >>> >> System 2 - Shows no USB stick connected > >>> >> System 3 - Gives error when trying to save (memory error) > >>> >> System 4 - Says unidentified USB > >>> >> (Windows PC - Always works) > >>> >> (Linux PC - Always works) > >>> >> > >>> >> At first I thought this was due to minor subtleties of how the > >>> >> g_mass_storage device was being presented as a standard Sandisk USB > >>> >> memory stick works fine in all systems. > >>> >> > >>> >> However I then started to notice some unusual behaviour, if rather > >>> >> than doing a reboot (and wiping it fresh), I kept the power running > >>> >> and moved it between machines. > >>> >> > >>> >> If I started with System 1 first, then systems 2, 3, 4 would all > >>> >> recognise/write to it OK. ... > OK I've had another play about with things this afternoon and > annotated the dmesg outputs to describe what I was doing at each > point. > > I haven't yet tried to recompile the kernel as that seems a slightly > slow process on the Pi (due to processing speed) and it make take me a > few goes to get it right - I thought I'd just check back initially in > case these logs provide sufficient clues! Obviously if not then I'll > look into that more. > > The key bit to my untrained eye seemed to be that until the line > 'g_mass_storage gadget: high-speed config #1: Linux File-Backed > Storage' appears, the Pi is unreadable by Systems 2-4. After that has > appeared in then appears to be readable, even though when connecting > to System 2 it (understandably and correctly) shows as low-speed > instead. Stop/start g_mass_storage doesn't appear to make a > difference. I agree. In fact, your logs seem to indicate pretty clearly that the problem doesn't lie in g_mass_storage at all, but rather in the dwc2 USB Device Controller driver. I have CC'ed the maintainer of the dwc2 driver. Here's the first log: > [ 15.891896] Mass Storage Function, version: 2009/09/11 > [ 15.891929] LUN: removable file: (no medium) > [ 15.892120] LUN: removable file: /home/pi/piusb.bin > [ 15.892135] Number of LUNs=1 > [ 15.894168] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 > [ 15.894200] g_mass_storage gadget: g_mass_storage ready > [ 15.894245] dwc2 2098.usb: dwc2_hsotg_enqueue_setup: failed queue (-11) > [ 15.897276] dwc2 2098.usb: bound driver g_mass_storage > CONNECTED TO SYSTEM 2 > [ 263.798965] dwc2 2098.usb: new device is low-speed > [ 269.497623] dwc2 2098.usb: new device is low-speed > [ 275.115548] dwc2 2098.usb: new device is low-speed > STILL NOT SHOWING UP ON SYSTEM 2 SO UNPLUGGED > (no extra message) Connecting at low speed is definitely a bug. The UDC driver should have connected at full speed. (It's possible that the log message is wrong, and the device really did connect at full speed. But if that were so, more log messages would have shown up.) > NOW PLUGGED IN TO WINDOWS 10 LAPTOP > (after a second, file browser opened showing root folder of memory storage) > [ 446.454380] dwc2 2098.usb: new device is high-speed > [ 452.045884] dwc2 2098.usb: new device is high-speed > [ 452.204357] dwc2 2098.usb: new device is high-speed > [ 452.305171] dwc2 2098.usb: new address 7 > [ 452.402701] g_mass_storage gadget: high-speed config #1: Linux File-Backed > Storage High speed would also be correct. I assume that your System 2 doesn't support high speed, however. > DISCONNECTED AND RECONNECTED TO SYSTEM 2 > [ 522.097785] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:176 > dwc2_hsotg_init_fifo+0x188/0x1a8 [dwc2]() > [ 522.097802] Modules linked in: g_mass_storage bnep hci_uart btbcm > bluetooth brcmfmac brcmutil snd_bcm2835 cfg80211 rfkill snd_pcm snd_timer snd > dwc2 bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio usb_f_mass_storage > libcomposite udc_core ipv6 > [ 522.097906] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.50+ #970 > [ 522.097918] Hardware name
Re: JMS567 USB3.0 scsi scan error
On Mon, 10 Jul 2017, Oliver Neukum wrote: > Am Donnerstag, den 06.07.2017, 14:32 -0700 schrieb Grégoire Gentil : > > Hi, > > > This might be a follow-up of: > > https://www.spinics.net/lists/linux-usb/msg157437.html > > https://www.spinics.net/lists/linux-usb/msg153647.html > > It does not look like that. > > > I have bought this adapter: > > http://www.ebay.com/itm/122523342593 > > > > > > The chip has the following marking: > > JM JMS567 > > http://www.jmicron.com/PDF/brief/jms567.pdf > > > > > > My laptop is running: > > Linux yoga 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57 > > UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > > > > LSB Version: > > core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch > > Distributor ID: Ubuntu > > Description:Ubuntu 16.04.2 LTS > > Release:16.04 > > Codename: xenial > > > > > > When I plug the device, I get the following error message: > > [ 1503.223516] usb 1-7: new high-speed USB device number 10 using xhci_hcd > > [ 1503.444964] usb 1-7: New USB device found, idVendor=152d, idProduct=0539 > > [ 1503.444970] usb 1-7: New USB device strings: Mfr=1, Product=2, > > SerialNumber=3 > > [ 1503.444973] usb 1-7: Product: USB to ATA/ATAPI Bridge > > [ 1503.444976] usb 1-7: Manufacturer: JMicron > > [ 1503.444979] usb 1-7: SerialNumber: 00A12345789F > > [ 1503.447024] scsi host1: uas > > [ 1511.457666] scsi 1:0:0:0: scsi scan: 96 byte inquiry failed. Consider > > BLIST_INQUIRY_36 for this device > > > > > > The device is working on Windows 10. > > > > > > Any idea what could be the problem? > > The old storage driver unconditionally limits inquiries to 36 bytes. UAS does > not > have that limit. That seems to be a bit optimistic. Could you test the > attached patch? If there's no particular benefit to 96-byte inquiries, it would be better to apply this limit unconditionally than to make a quirk for it. (Not to mention that your proposed patch has a copy & paste error -- the quirk number wasn't incremented.) Besides, we're running out of bits for quirks. Only a few more will require expanding it to a 64-bit field. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
Hi again,
Felipe Balbi writes:
> Hi,
>
> Minas Harutyunyan writes:
>> USB CV driver stack doesn't perform USB RESET after device disconnect/
>> connect, so need to reset to zero DEVADDR field in DCFG to pass
>> enumeration again.
>>
>> Signed-off-by: Minas Harutyunyan
>> ---
>> drivers/usb/dwc2/gadget.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
>> index 98a4a79e7f6e..deb3d901b99d 100644
>> --- a/drivers/usb/dwc2/gadget.c
>> +++ b/drivers/usb/dwc2/gadget.c
>> @@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg)
>> return;
>>
>> hsotg->connected = 0;
>> +/* On disconnect reset device address to zero */
>> +__bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK);
>> +
>
> Which of the tests are you talking about? Which particular USB CV are
> you running?
>
> I don't remember ever seeing this with dwc3. How should I go about
> triggering this problem? If this was really the case, then we would have
> this on *all* UDCs.
>
> I just did a fresh install of USB 3 Gen X CV (that I just download from
> usb.org). Ran Chapter 9 tests against a HS dwc3 board I have around and
> I can't see the problem you're talking about.
>
> Here are all my non-endpoint interrupt events in order. Test passes
> fine. If disconnect, reconnect and run the tests again, then Reset will
> be driven on the bus which will cause address to be reset.
>
> Can you share more details about the problem you're facing?
I've been looking at dwc2 for a while and I think this is a bug in
dwc2_hsotg_irq() on the branch for GINTSTS_USBRST. I don't have docs for
dwc2.
Nowhere in that function is driver making sure DCFG_DEVADDR is cleared
to 0. In fact, there nowhere at all in the driver where you're making
sure to reset device address:
$ git --no-pager grep --color -nH -e DCFG_DEVADDR_ -- drivers/usb/dwc2/
drivers/usb/dwc2/gadget.c:1837: dcfg &= ~DCFG_DEVADDR_MASK;
drivers/usb/dwc2/gadget.c:1839: DCFG_DEVADDR_SHIFT) &
DCFG_DEVADDR_MASK;
drivers/usb/dwc2/hw.h:426:#define DCFG_DEVADDR_MASK (0x7f << 4)
drivers/usb/dwc2/hw.h:427:#define DCFG_DEVADDR_SHIFT4
drivers/usb/dwc2/hw.h:428:#define DCFG_DEVADDR_LIMIT0x7f
If we look into gadget.c on those lines, here's what we have:
static void dwc2_hsotg_process_control(struct dwc2_hsotg *hsotg,
struct usb_ctrlrequest *ctrl)
{
[...]
struct dwc2_hsotg_ep *ep0 = hsotg->eps_out[0];
int ret = 0;
u32 dcfg;
dev_dbg(hsotg->dev,
"ctrl Type=%02x, Req=%02x, V=%04x, I=%04x, L=%04x\n",
ctrl->bRequestType, ctrl->bRequest, ctrl->wValue,
ctrl->wIndex, ctrl->wLength);
if (ctrl->wLength == 0) {
ep0->dir_in = 1;
hsotg->ep0_state = DWC2_EP0_STATUS_IN;
} else if (ctrl->bRequestType & USB_DIR_IN) {
ep0->dir_in = 1;
hsotg->ep0_state = DWC2_EP0_DATA_IN;
} else {
ep0->dir_in = 0;
hsotg->ep0_state = DWC2_EP0_DATA_OUT;
}
if ((ctrl->bRequestType & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl->bRequest) {
case USB_REQ_SET_ADDRESS:
hsotg->connected = 1;
dcfg = dwc2_readl(hsotg->regs + DCFG);
dcfg &= ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl->wValue) <<
DCFG_DEVADDR_SHIFT) & DCFG_DEVADDR_MASK;
dwc2_writel(dcfg, hsotg->regs + DCFG);
dev_info(hsotg->dev, "new address %d\n", ctrl->wValue);
ret = dwc2_hsotg_send_reply(hsotg, ep0, NULL, 0);
return;
[...]
}
So you only touch DEVADDR from SetAddress. That's clearly a bug
elsewhere in the driver and is *NOT* related to USB CV at all. Please
fix this driver properly instead of hacking around unrelated functions.
Disconnect IRQ is *NOT* supposed to clear device address. That's a job
for Reset IRQ.
--
pbalbi
signature.asc
Description: PGP signature
Re: [PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
Hi, Minas Harutyunyan writes: > USB CV driver stack doesn't perform USB RESET after device disconnect/ > connect, so need to reset to zero DEVADDR field in DCFG to pass > enumeration again. > > Signed-off-by: Minas Harutyunyan > --- > drivers/usb/dwc2/gadget.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 98a4a79e7f6e..deb3d901b99d 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg) > return; > > hsotg->connected = 0; > + /* On disconnect reset device address to zero */ > + __bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK); > + Which of the tests are you talking about? Which particular USB CV are you running? I don't remember ever seeing this with dwc3. How should I go about triggering this problem? If this was really the case, then we would have this on *all* UDCs. I just did a fresh install of USB 3 Gen X CV (that I just download from usb.org). Ran Chapter 9 tests against a HS dwc3 board I have around and I can't see the problem you're talking about. Here are all my non-endpoint interrupt events in order. Test passes fine. If disconnect, reconnect and run the tests again, then Reset will be driven on the bus which will cause address to be reset. Can you share more details about the problem you're facing? events === irq/34-dwc3-1609 [001] d..1 13907.710095: dwc3_event: event (0001): Disconnect: [U0] irq/34-dwc3-1609 [001] d..1 13958.860840: dwc3_event: event (0001): Disconnect: [U0] irq/34-dwc3-1609 [001] d..1 14161.547651: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14161.602254: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14163.314174: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14163.368819: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14168.706773: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14168.758551: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14190.027840: dwc3_event: event (0401): WakeUp [U0] irq/34-dwc3-1609 [001] d..1 14203.428377: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14203.479869: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14203.739212: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14203.790550: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14204.025838: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14204.077335: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14204.329353: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14204.380840: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14204.629167: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14204.680503: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14204.941740: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14204.993141: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14205.233103: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14205.285111: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14205.543597: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14205.595033: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14205.840592: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14205.892126: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14206.139094: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14206.190724: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14206.442184: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14206.493527: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14206.739330: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14206.790758: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14207.040100: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14207.091497: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d..1 14207.343450: dwc3_event: event (0101): Reset [U0] irq/34-dwc3-1609 [001] d..1 14207.394870: dwc3_event: event (0201): Connection Done [U0] irq/34-dwc3-1609 [001] d
Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson wrote: > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern wrote: >> On Sat, 8 Jul 2017, Alan Robertson wrote: >> >>> On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern >>> wrote: >>> > On Fri, 7 Jul 2017, Alan Robertson wrote: >>> > >>> >> Sorry to return to this topic & appreciate it might be either specific >>> >> to either the Pi or the system(s) I'm connecting it to, but have now >>> >> had time to try a few more combinations out and would appreciate any >>> >> thoughts from the experts here. >>> >> >>> >> To give some extra background - I've got the Pi configured to >>> >> automatically overwrite the mass storage device filestore upon boot, >>> >> so it is always presenting a fresh filesystem. Each system below is >>> >> made by a different manufacturer and is a closed system, so I have no >>> >> ability to perform any diagnostics at that end. >>> >> >>> >> System 1 - Always works >>> >> System 2 - Shows no USB stick connected >>> >> System 3 - Gives error when trying to save (memory error) >>> >> System 4 - Says unidentified USB >>> >> (Windows PC - Always works) >>> >> (Linux PC - Always works) >>> >> >>> >> At first I thought this was due to minor subtleties of how the >>> >> g_mass_storage device was being presented as a standard Sandisk USB >>> >> memory stick works fine in all systems. >>> >> >>> >> However I then started to notice some unusual behaviour, if rather >>> >> than doing a reboot (and wiping it fresh), I kept the power running >>> >> and moved it between machines. >>> >> >>> >> If I started with System 1 first, then systems 2, 3, 4 would all >>> >> recognise/write to it OK. >>> >> >>> >> I then copied a backup of the filesystem after it had been in System 1 >>> >> - however that still didn't seem to solve the problem after a reboot. >>> >> What I did then notice though was that if I powered the Pi up and then >>> >> first connected it to a Windows system it then worked fine when >>> >> plugged in to the others. To be clear I didn't read/write any files >>> >> to the device, just started it up, then plugged it into Windows, saw >>> >> the home directory on the USB open, then unplugged it and plugged it >>> >> into one of the other systems - they all now recognised it. >>> >> >>> >> I tried starting/stopping g_mass_storage but that in itself didn't >>> >> seem to do it. >>> > >>> > Sorry, this is unclear. >>> > >>> > 1. By starting/stopping g_mass_storage, do you mean doing: >>> > >>> > rmmod g_mass_storage >>> > modprobe g_mass_storage file=... >>> >>> Yes - at least I believe I've effectively been doing the same albeit a >>> slightly different version of stopping... >>> sudo modprobe -rv g_mass_storage >> >> That's basically the same as rmmod g_mass_storage. > > Good, that's what I hoped. > >>> and then to start... >>> sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0 >>> removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x0126 >>> iManufacturer="SanDisk" iProduct="Cruzer Switch" >>> iSerialNumber="4C597515973308202393" >>> >>> >>> > 2. Did you start/stop g_mass_storage after plugging the device >>> > into a Windows system or System 1? Or did you do this after >>> > booting the device but not plugging it into anything? >>> >>> Upon startup it mounts the filesystem as read-only: >>> sudo losetup -o 1048576 /dev/loop0 /home/pi/piusb.bin >>> sudo mount -t vfat -r /dev/loop0 /mnt >>> >>> Then copies contents off, unmounts it, overwrites pisub.bin with >>> backup blank filesystem, then remounts the filesystem read-only again >>> and starts USB. >> >> This does not answer the question I asked. Had you plugged the device >> into a Windows system or System 1 before you stopped/started >> g_mass_storage? > > Ah, sorry - I was providing this info to help answer the second part > of your question 'did you do this after booting the device'. > > I did not start/stop g_mass_storage before or after plugging it into a > Windows system or System 1. I simply let it run through its normal > boot process, then plugged it into Windows PC (or System 1), then > unplugged from there and plugged into any of the other systems. If I > omitted the step of plugging into WPC/Sys1 it would then not be > recognised by Sys2/3/4. > >>> I didn't do anything when plugging into Windows system or System 1 - >>> just started up, plugged into one of those, unplugged and then plugged >>> into one of the other systems. >> >> What happens if you plug the device into either a Windows system or >> System 1, then unplug it, then stop/start g_mass_storage, and then plug >> the device into one of systems 2-4? > > Good question - the systems are at work so will need to do that on > Monday, but I hadn't tried that permutation. > >>> > 3. By "that in itself didn't seem to do it", do you mean that >>> > starting/stopping g_mass_storage resulted in no change to the >>> > behavior? Or did it always l
Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
On Mon, Jul 10, 2017 at 11:07 AM, Felipe Balbi wrote: > > Hi, > > Paul Zimmerman writes: > > Did you try enabling verbose debugging in g_mass_storage? This > > requires setting CONFIG_USB_GADGET_DEBUG and CONFIG_USB_GADGET_VERBOSE > > in the kernel configuration and then rebuilding g_mass_storage.ko. > > And at runtime you may need to enable dynamic debugging by doing > > > > echo 'module g_mass_storage =p' > > >/sys/kernel/dynamic_debug/control > > > > before plugging the device into anything. Then compare the contents of > > the dmesg log for the different scenarios. In particular, look for > > differences between plugging it into System 2 (say) right after boot > > vs. after plugging it into System 1. > > OK interesting - I'll need to do some searching to understand how to > change that and rebuild g_mass_storage.ko but I like the idea of > seeing more detail about what is happening as the systems are closed > so I'm unable to do any troubleshooting at that end. Do you have any experience in building a kernel for the Raspberry Pi? The procedure is explained on several web sites, but you have to know what you're doing. >>> >>> No I don't - I'll have a read over things to see what I can suss out. >> >> The 'Linux File-Stor Gadget' string is part of the SCSI inquiry data, and >> is set by the fsg_common_set_inquiry_string() function in f_mass_storage.c. >> This must be what the problematic host systems are reacting to, and not any >> of the USB info that you have overridden. It looks like there is a way to >> override this string using configfs, perhaps Alan will know how to do this. > > There should be a file named "inquiry_string" on mass storage's function > directory: > > # find /c/usb_gadget/storage/functions/mass_storage.1/ > /c/usb_gadget/storage/functions/mass_storage.1/ > /c/usb_gadget/storage/functions/mass_storage.1/lun.0 > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/inquiry_string > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/nofua > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/cdrom > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/removable > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/ro > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/file > /c/usb_gadget/storage/functions/mass_storage.1/stall > > Just write your string to it: > > # echo "My Inquiry String" > > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/inquiry_string Thanks Felipe & Paul - that's useful to know and I'll have a wee play about with it to see if I can get it showing more consistently. However now I can get it working reliably with plugging it into another system first I suspect that this isn't quite the problem - I'm about to reply to Alan's message shortly with dmesg logs to see if that helps clarify things at all! Cheers Alan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc2: gadget: On disconnect reset device address to zero
USB CV driver stack doesn't perform USB RESET after device disconnect/
connect, so need to reset to zero DEVADDR field in DCFG to pass
enumeration again.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 98a4a79e7f6e..deb3d901b99d 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3174,6 +3174,9 @@ void dwc2_hsotg_disconnect(struct dwc2_hsotg *hsotg)
return;
hsotg->connected = 0;
+ /* On disconnect reset device address to zero */
+ __bic32(hsotg->regs + DCFG, DCFG_DEVADDR_MASK);
+
hsotg->test_mode = 0;
for (ep = 0; ep < hsotg->num_of_eps; ep++) {
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMS567 USB3.0 scsi scan error
Am Donnerstag, den 06.07.2017, 14:32 -0700 schrieb Grégoire Gentil :
Hi,
> This might be a follow-up of:
> https://www.spinics.net/lists/linux-usb/msg157437.html
> https://www.spinics.net/lists/linux-usb/msg153647.html
It does not look like that.
> I have bought this adapter:
> http://www.ebay.com/itm/122523342593
>
>
> The chip has the following marking:
> JM JMS567
> http://www.jmicron.com/PDF/brief/jms567.pdf
>
>
> My laptop is running:
> Linux yoga 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> LSB Version:
> core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:printing-9.20160110ubuntu0.2-amd64:printing-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
> Distributor ID: Ubuntu
> Description: Ubuntu 16.04.2 LTS
> Release: 16.04
> Codename: xenial
>
>
> When I plug the device, I get the following error message:
> [ 1503.223516] usb 1-7: new high-speed USB device number 10 using xhci_hcd
> [ 1503.444964] usb 1-7: New USB device found, idVendor=152d, idProduct=0539
> [ 1503.444970] usb 1-7: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 1503.444973] usb 1-7: Product: USB to ATA/ATAPI Bridge
> [ 1503.444976] usb 1-7: Manufacturer: JMicron
> [ 1503.444979] usb 1-7: SerialNumber: 00A12345789F
> [ 1503.447024] scsi host1: uas
> [ 1511.457666] scsi 1:0:0:0: scsi scan: 96 byte inquiry failed. Consider
> BLIST_INQUIRY_36 for this device
>
>
> The device is working on Windows 10.
>
>
> Any idea what could be the problem?
The old storage driver unconditionally limits inquiries to 36 bytes. UAS does
not
have that limit. That seems to be a bit optimistic. Could you test the attached
patch?
Regards
Oliver
From 60fd3e2d0e5c7e7fbe5984bac52e10d224f65d98 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 10 Jul 2017 14:58:21 +0200
Subject: [PATCH] uas: introduce quirk to reduce inquiry to 36 bytes
Usually UAS devices get the correct length of the enquiry right.
But there are a few quirky devices needing special cases.
So introduce a quirk.
Signed-off-by: Oliver Neukum
---
drivers/usb/storage/uas.c | 3 +++
drivers/usb/storage/unusual_devs.h | 7 +++
include/linux/usb_usual.h | 2 ++
3 files changed, 12 insertions(+)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 5ef014ba6ae8..97602d77b1d7 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -799,6 +799,9 @@ static int uas_slave_alloc(struct scsi_device *sdev)
sdev->hostdata = devinfo;
+ if (devinfo->flags & US_FL_INQUIRY_36)
+ sdev->inquiry_len = 36;
+
/*
* USB has unusual DMA-alignment requirements: Although the
* starting address of each scatter-gather element doesn't matter,
diff --git a/drivers/usb/storage/unusual_devs.h b/drivers/usb/storage/unusual_devs.h
index 5a70c33ef0e0..c850613f1c94 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -2099,6 +2099,13 @@ UNUSUAL_DEV( 0x14cd, 0x6600, 0x0201, 0x0201,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_IGNORE_RESIDUE ),
+/* Reported by Grégoire Gentil */
+UNUSUAL_DEV( 0x152d, 0x0539, 0x, 0x,
+"JMicron",
+"USB to ATA/ATAPI Bridge",
+USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+US_FL_INQUIRY_36 ),
+
/* Reported by Michael Büsch */
UNUSUAL_DEV( 0x152d, 0x0567, 0x0114, 0x0116,
"JMicron",
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 0aae1b2ee931..d3cf3d921ec6 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -83,6 +83,8 @@
/* Cannot handle REPORT_LUNS */ \
US_FLAG(ALWAYS_SYNC, 0x2000) \
/* lies about caching, so always sync */ \
+ US_FLAG(INQUIRY_36, 0x2000)\
+ /* needs a shortened enquiry */ \
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
2.12.3
Re: [PATCH 1/3] mfd: Add support for FTDI FT232H devices
On Thu, Jul 06, 2017 at 10:49:16PM +0200, Anatolij Gustschin wrote:
> Add USB part with common functions for USB-GPIO/I2C/SPI master
> adapters. These allow communication with chip's control, transmit
> and receive endpoints and will be used by various FT232H drivers.
> +static const struct mfd_cell ftdi_cells[] = {
> + { .name = "ftdi-cbus-gpio", },
> + { .name = "ftdi-mpsse-i2c", },
> + { .name = "ftdi-mpsse-spi", },
> + { .name = "ftdi-fifo-fpp-mgr", },
> +};
Correct me if I'm wrong, but aren't these modes really mutually
exclusive, possibly with exception of cbus-gpio (some pins are at least
available as GPIOs in MPSSE mode)? Then MFD is not is not the right fit
here either.
And as David Laight already pointed out, your ftdi-fifo-fpp-mgr driver
seems too application specific for a generic chip like this.
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 1/3] mfd: Add support for FTDI FT232H devices
On Fri, Jul 07, 2017 at 11:53:29AM +0200, Anatolij Gustschin wrote:
> On Fri, 07 Jul 2017 09:48:48 +0200
> Bjørn Mork bj...@mork.no wrote:
>
> >[adding Johan on the CC list]
> >
> >Anatolij Gustschin writes:
> >
> >> +static struct usb_device_id ftdi_mfd_table[] = {
> >> + { USB_DEVICE(0x0403, 0x6014) },
> >> + {}
> >> +};
> >> +MODULE_DEVICE_TABLE(usb, ftdi_mfd_table);
> >
> >This device ID is currently handled by the ftdi_sio driver, so I believe
> >you at least have to explain how you intend these two drivers to
> >cooperate...
>
> these drivers cannot cooperate, the different ftdi function modes
> use same device pins as in UART mode. So, you either can use the
> device in UART interface mode or in some different mode. I do not
> load the ftdi_sio module or do unbind the USB device from the
> ftdio_sio driver and bind it to the mfd driver, e.g.:
>
> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/unbind"
> sh -c "echo -n "3-2:1.0" > /sys/bus/usb/drivers/ftdi-mfd/bind"
I'm afraid that's not good enough. If we're going to support a non-UART
mode through a separate driver, we need to have all drivers for these
devices be able to retrieve the current mode during probe and only bind
when the mode matches.
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 1/2] usb: core: unlink urbs from the tail of the endpoint's urb_list
On Fri, Jul 07, 2017 at 08:19:08PM -0400, Alan Stern wrote:
> On Fri, 7 Jul 2017, Bin Liu wrote:
>
> > On Fri, Jul 07, 2017 at 11:56:53AM -0400, Alan Stern wrote:
> > > On Fri, 7 Jul 2017, Bin Liu wrote:
> > >
> > > > While unlink an urb, if the urb has been programmed in the controller,
> > > > the controller driver might do some hw related actions to tear down the
> > > > urb.
> > > >
> > > > Currently usb_hcd_flush_endpoint() passes each urb from the head of the
> > > > endpoint's urb_list to the controller driver, which could make the
> > > > controller driver think each urb has been programmed and take the
> > > > unnecessary actions for each urb.
> > > >
> > > > This patch changes the behavior in usb_hcd_flush_endpoint() to pass the
> > > > urbs from the tail of the list, to avoid any unnecessary actions in an
> > > > controller driver.
> > > >
> > > > Signed-off-by: Bin Liu
> > > > ---
> > > > drivers/usb/core/hcd.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > > > index 5dea98358c05..6839c176c701 100644
> > > > --- a/drivers/usb/core/hcd.c
> > > > +++ b/drivers/usb/core/hcd.c
> > > > @@ -1878,7 +1878,7 @@ void usb_hcd_flush_endpoint(struct usb_device
> > > > *udev,
> > > > /* No more submits can occur */
> > > > spin_lock_irq(&hcd_urb_list_lock);
> > > > rescan:
> > > > - list_for_each_entry (urb, &ep->urb_list, urb_list) {
> > > > + list_for_each_entry_reverse (urb, &ep->urb_list, urb_list) {
> > > > int is_in;
> > > >
> > > > if (urb->unlinked)
> > >
> > > Acked-by: Alan Stern
> > >
> > > But you might want to get rid of the extra space before the open paren
> > > (what does checkpatch.pl say?).
> >
> > Yes, it complains, but the whole file has this style, so I didn't change
> > it. But I can remove it if we want to gradually fix the coding style
> > problem.
>
> That's how we have been handling these things in the USB subsystem.
> Whenever code containing extra spaces gets changed, the new code leaves
> out the spaces.
Thanks Alan, I will remove the spaces when I am ready submitting those
patches for next -rc in a couple weeks if no other comments collected.
Regards,
-Bin.
--
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: Warning dump on OMAP-L138 when g_zero module is removed
On Thursday 06 July 2017 10:43 PM, Alexandre Bailon wrote: > On 06/29/2017 03:50 PM, Sekhar Nori wrote: >> Hi Alexandre, Bin, >> >> With latest linux-next, I see a warning dump when I remove g_zero[1] on >> OMAP-L138 LCDK board. I am building the kernel with davinci_all_defconfig. >> >> It is not present in latest mainline because the warnings are introduced >> with CPPI DMA getting enabled in latest -next. >> >> Subsequent insertion of g_ether leads to a warning too[2], although the >> gadget seems to work (ping test). >> >> Since these are pretty annoying, it will be nice to get rid of them. I >> have not been able to debug any further. But if you have >> ideas/experiments to try, I can do that. > I got a lot of these warnings during development but it was only for the > host mode. > If I remember correctly, the cause was a race between the teardown > function and the interrupt handler. > The teardwon descriptor was pop from the queue by the interrupt handler, > preventing cppi41_tear_down_chan() to get it, which will result after > some retries to a couple of warnings. > > I will take a look to see if that is the same issue. Thanks! I also see similar warnings under fast ping traffic and g_ether inserted on LCDK. They dont come immediately though. Only after an hour or so under traffic. I can those provide logs too if its going to be helpful. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: g_mass_storage emulation of flash drive - difficulties with passing vendor/product ID
Hi, Paul Zimmerman writes: > Did you try enabling verbose debugging in g_mass_storage? This > requires setting CONFIG_USB_GADGET_DEBUG and CONFIG_USB_GADGET_VERBOSE > in the kernel configuration and then rebuilding g_mass_storage.ko. > And at runtime you may need to enable dynamic debugging by doing > > echo 'module g_mass_storage =p' > >/sys/kernel/dynamic_debug/control > > before plugging the device into anything. Then compare the contents of > the dmesg log for the different scenarios. In particular, look for > differences between plugging it into System 2 (say) right after boot > vs. after plugging it into System 1. OK interesting - I'll need to do some searching to understand how to change that and rebuild g_mass_storage.ko but I like the idea of seeing more detail about what is happening as the systems are closed so I'm unable to do any troubleshooting at that end. >>> >>> Do you have any experience in building a kernel for the Raspberry Pi? >>> The procedure is explained on several web sites, but you have to know >>> what you're doing. >> >> No I don't - I'll have a read over things to see what I can suss out. > > The 'Linux File-Stor Gadget' string is part of the SCSI inquiry data, and > is set by the fsg_common_set_inquiry_string() function in f_mass_storage.c. > This must be what the problematic host systems are reacting to, and not any > of the USB info that you have overridden. It looks like there is a way to > override this string using configfs, perhaps Alan will know how to do this. There should be a file named "inquiry_string" on mass storage's function directory: # find /c/usb_gadget/storage/functions/mass_storage.1/ /c/usb_gadget/storage/functions/mass_storage.1/ /c/usb_gadget/storage/functions/mass_storage.1/lun.0 /c/usb_gadget/storage/functions/mass_storage.1/lun.0/inquiry_string /c/usb_gadget/storage/functions/mass_storage.1/lun.0/nofua /c/usb_gadget/storage/functions/mass_storage.1/lun.0/cdrom /c/usb_gadget/storage/functions/mass_storage.1/lun.0/removable /c/usb_gadget/storage/functions/mass_storage.1/lun.0/ro /c/usb_gadget/storage/functions/mass_storage.1/lun.0/file /c/usb_gadget/storage/functions/mass_storage.1/stall Just write your string to it: # echo "My Inquiry String" > /c/usb_gadget/storage/functions/mass_storage.1/lun.0/inquiry_string -- balbi signature.asc Description: PGP signature
[PATCH] net: cdc_ncm: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
13275 928 1 14204377c drivers/net/usb/cdc_ncm.o
File size After adding 'const':
textdata bss dec hex filename
13339 864 1 14204377c drivers/net/usb/cdc_ncm.o
Signed-off-by: Arvind Yadav
---
drivers/net/usb/cdc_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index d103a1d..b401ba9 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -367,7 +367,7 @@ static DEVICE_ATTR(name, S_IRUGO, cdc_ncm_show_##name, NULL)
NULL,
};
-static struct attribute_group cdc_ncm_sysfs_attr_group = {
+static const struct attribute_group cdc_ncm_sysfs_attr_group = {
.name = "cdc_ncm",
.attrs = cdc_ncm_sysfs_attrs,
};
--
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] net: usb: qmi_wwan: constify attribute_group structures.
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
16831 464 0 17295438f drivers/net/usb/qmi_wwan.o
File size After adding 'const':
textdata bss dec hex filename
16895 400 0 17295438f drivers/net/usb/qmi_wwan.o
Signed-off-by: Arvind Yadav
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 5894e3c..b2ddd5c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -434,7 +434,7 @@ static ssize_t del_mux_store(struct device *d, struct
device_attribute *attr, c
NULL,
};
-static struct attribute_group qmi_wwan_sysfs_attr_group = {
+static const struct attribute_group qmi_wwan_sysfs_attr_group = {
.name = "qmi",
.attrs = qmi_wwan_sysfs_attrs,
};
--
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] usb: isp1760: compress return logic into one line
Am Sonntag, den 09.07.2017, 21:00 -0500 schrieb Gustavo A. R. Silva : > Simplify return logic to avoid unnecessary variable assignment. > > This issue was detected using Coccinelle and the following > semantic patch: > Hi, I need to ask: Where is the improvement? The compiler does not bother and for the human reader you do not do anything obvious and you decreased grepability. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
