Re: [PATCH 1/1] usb: chipidea: host: add .bus_suspend quirk
On Tue, Dec 30, 2014 at 10:16:39AM -0500, Alan Stern wrote: > On Tue, 30 Dec 2014, Peter Chen wrote: > > > On Mon, Dec 29, 2014 at 10:44:28AM -0500, Alan Stern wrote: > > > On Mon, 29 Dec 2014, Peter Chen wrote: > > > > > > > For chipidea, its resume sequence is not-EHCI compatible, see > > > > below description for FPR at portsc. So in order to send SoF in > > > > time for remote wakeup sequence(within 3ms), the RUN/STOP bit must > > > > be set before the resume signal is ended. > > > > > > > > Force Port Resume - RW. Default = 0b. > > > > 1= Resume detected/driven on port. > > > > 0=No resume (K-state) detected/driven on port. > > > > Host mode: > > > > Software sets this bit to one to drive resume signaling. The Controller > > > > sets this bit to '1' if > > > > a J-to-K transition is detected while the port is in the Suspend state. > > > > When this bit > > > > transitions to a '1' because a J-to-K transition is detected, the Port > > > > Change Detect bit in > > > > the USBSTS register is also set to '1'. This bit will automatically > > > > change to '0' after the > > > > resume sequence is complete. This behavior is different from EHCI where > > > > the controller > > > > driver is required to set this bit to a '0' after the resume duration > > > > is timed in the driver. > > > > Note that when the controller owns the port, the resume sequence > > > > follows the defined > > > > > > > > sequence documented in the USB Specification Revision 2.0. The resume > > > > signaling > > > > (Full-speed 'K') is driven on the port as long as this bit remains a > > > > '1'. This bit will remain > > > > a '1' until the port has switched to idle. Writing a '0' has no affect > > > > because the port > > > > controller will time the resume operation, clear the bit and the port > > > > control state switches > > > > to HS or FS idle. > > > > This field is '0' if Port Power(PP) is '0' in host mode. > > > > > > > > This bit is not-EHCI compatible. > > > > > > If you really want to do this, go ahead. But see below. > > > > > > > Any other solutions for this (Let the SoF send in time within 3ms after > > resume > > signal has ended)? > > No, I don't have any good solutions. What this patch does isn't > suitable for EHCI controllers in general, because it disobeys section > 4.3 of the EHCI spec: > > When system software intends to suspend the entire bus, it should > selectively suspend all enabled ports, then shut off the host > controller by setting the Run/Stop bit in the USBCMD register > to a zero. The EHCI module can then be placed into a lower > device state via the PCI power management interface (See > Appendix A). > > With this patch, the Run/Stop bit gets set back to 1. > > When a wake event occurs the system will resume operation and > system software will eventually set the Run/Stop bit to a one > and resume the suspended ports. Software must not set the > Run/Stop bit to a one until it is confirmed that the clock to > the host controller is stable. > > With this patch, the Run/Stop bit remains equal to 1 even while the > clock to the host controller is turned off. > > The only solution I can think of is not very satisfactory. Suppose the > controller doesn't send any SoF packets within 3 ms of getting a wakeup > signal. Then the device will go back into suspend. Later on, when the > controller starts running, the hub driver will see that the device > requested a wakeup and will resume the device. Thanks, Alan. If the roothub will send resume before sending SoF, it should be ok, I just remembered I had seen "disconnect" before due to host send SoF to suspended device, will check it again. > > > > > + tmp = ehci_readl(ehci, &ehci->regs->command); > > > > + tmp |= CMD_RUN; > > > > + ehci_writel(ehci, tmp, &ehci->regs->command); > > > > > > At this point, the bus isn't suspended any more. It is running. > > > > > > > The bus state is 'J' since the portsc.suspendM = 1, so the bus is > > suspended, correct? > > True, no packets are being sent out to the bus. But the circuitry in > the EHCI controller is running, generating SoF packets every 125 us > (even though they don't get sent anywhere). > It needs PHY is in active mode, otherwise, there is no 480M for USB2, and the PHY is usually in suspend mode after controller enters suspend. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: chipidea: host: add .bus_suspend quirk
On Wed, 31 Dec 2014, Peter Chen wrote: > > The only solution I can think of is not very satisfactory. Suppose the > > controller doesn't send any SoF packets within 3 ms of getting a wakeup > > signal. Then the device will go back into suspend. Later on, when the > > controller starts running, the hub driver will see that the device > > requested a wakeup and will resume the device. > > Thanks, Alan. > > If the roothub will send resume before sending SoF, it should be ok, I > just remembered I had seen "disconnect" before due to host send > SoF to suspended device, will check it again. There may be a problem, because the wakeup signal will cause the port to switch automatically from suspend to active status. This means it will use the high-speed terminations. But the device will go back into suspend when it doesn't get any SoF packets within 3 ms, so it will be using the full-speed terminations. Then when the host controller does start sending out SoF packets, the mismatched terminations will show up as a disconnect. (I really think this is a mistake in the USB spec. Allowing only 3 ms for a host system to turn itself on is not reasonable.) We could try putting the port back into suspend before turning on the Run/Stop bit. That might work -- but if we don't do it carefully, we will lose track of the fact that the device sent a wakeup signal. Can you try testing this approach to see if it will work? 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
Another Seagate USB 3 device that needs uas blacklisting - 0bc2:2321
Hi, Trying to use a Seagate Expansion 2TB disk 0bc2:2321 and getting errors like this; Dec 30 17:00:09 kiwis kernel: [882332.028518] sd 9:0:0:0: [sdb] uas_eh_abort_handler 88007397b500 tag 10, inflight: CMD OUT Dec 30 17:00:12 kiwis kernel: [882335.033621] scsi host9: uas_eh_task_mgmt: ABORT TASK timed out and much more... Using "usb-storage.quirks=0bc2:2321:u" as kernel arguments fixes the problem so I assume that the following patch would be appropriate. *** unusual_uas.h.orig 2014-12-18 19:20:12.0 -0800 --- unusual_uas.h 2014-12-31 11:36:03.0 -0800 *** *** 47,52 --- 47,59 USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NO_ATA_1X), + /* Reported by: Thomas Eriksson */ + UNUSUAL_DEV(0x0bc2, 0x2321, 0x, 0x, + "Seagate", + "Expansion", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_NO_ATA_1X), + /* https://bbs.archlinux.org/viewtopic.php?id=183190 */ UNUSUAL_DEV(0x0bc2, 0x3312, 0x, 0x, "Seagate", The lspci out for the controller is: USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 03) and here is the output of lsusb lsusb -v -d 0bc2:2321 Bus 009 Device 003: ID 0bc2:2321 Seagate RSS LLC Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0bc2 Seagate RSS LLC idProduct 0x2321 bcdDevice1.00 iManufacturer 2 Seagate iProduct3 Expansion iSerial 1 NA4A7WMK bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 121 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 36mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-in pipe (0x03) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32 Data-out pipe (0x04) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 15 MaxStreams 32
Re: [PATCH 1/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila wrote: > As noticed during suspend/resume operations, the IRQ can be unmasked > then disabled in suspend and eventually enabled in resume, but without > being unmasked. > > The current implementation does not take into account interactions > between mask/unmask and enable/disable interrupts, and thus in the > above scenarios the IRQs remain unactive. > > To fix this we removed the enable/disable operations as they fallback > to mask/unmask anyway. > > We also remove the pending bitmaks as it is already done in irq_data > (i.e. IRQS_PENDING). > > Signed-off-by: Octavian Purdila Patch applied for fixes. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work
On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila wrote: > Use the irq_chip bus_sync_unlock method to update hardware registers > instead of scheduling work from the mask/unmask methods. This simplifies > a bit the driver and make it more uniform with the other GPIO IRQ > drivers. > > Signed-off-by: Octavian Purdila Patch applied for fixes. Yours, Linus Walleij -- 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: Another Seagate USB 3 device that needs uas blacklisting - 0bc2:2321
Sorry, was a bit hasty there. Should have tested properly. The US_FL_NO_ATA_1X flag does not fix this problem, but the US_FL_IGNORE_UAS flag does. The patch should be *** unusual_uas.h.orig 2014-12-18 19:20:12.0 -0800 --- unusual_uas.h 2014-12-31 12:55:56.0 -0800 *** *** 47,52 --- 47,59 USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NO_ATA_1X), + /* Reported by: Thomas Eriksson */ + UNUSUAL_DEV(0x0bc2, 0x2321, 0x, 0x, + "Seagate", + "Expansion", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_IGNORE_UAS), + /* https://bbs.archlinux.org/viewtopic.php?id=183190 */ UNUSUAL_DEV(0x0bc2, 0x3312, 0x, 0x, "Seagate", -- 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: USB-serial console and lockdep
Hi Johan,
On 11/18/2014 11:18 AM, Johan Hovold wrote:
> I get this missing-lockdep-annotation warning which I haven't seen
> before when booting with a usb-serial console on 3.18-rc5. It's been a
> while since I last tested this, though, and the tty_ldisc_ref wasn't
> introduced until 833efc0ed19c ("USB: serial: invoke dcd_change ldisc's
> handler.").
Sorry it took me so long to finally look at this -- at least I'm looking
at it in the same year ;) (in my tzone anyway)
Is this easily reproducible?
Because for lockdep to be trying to register the ldsem lock class
from the tty_ldisc_ref() means that no tty has yet been opened [see 1].
So how did the call to tty_port_tty_get() in pl2303_update_line_status()
return a tty?
If you can easily reproduce this, I can supply you with a debug patch
to find out what's going on.
Regards,
Peter Hurley
> [ 10.575225] usbserial: USB Serial support registered for pl2303
> [ 10.575561] pl2303 1-2.1:1.0: pl2303 converter detected
> [ 10.627563] usb 1-2.1: pl2303 converter now attached to ttyUSB0
> [ 10.650939] INFO: trying to register non-static key.
> [ 10.651000] the code is fine but needs lockdep annotation.
> [ 10.651000] turning off the locking correctness validator.
> [ 10.651031] CPU: 0 PID: 68 Comm: udevd Tainted: GW 3.18.0-rc5
> #10
> [ 10.651092] [] (unwind_backtrace) from []
> (show_stack+0x20/0x24)
> [ 10.651123] [] (show_stack) from []
> (dump_stack+0x24/0x28)
> [ 10.651184] [] (dump_stack) from []
> (__lock_acquire+0x1e50/0x2004)
> [ 10.651214] [] (__lock_acquire) from []
> (lock_acquire+0xe4/0x18c)
> [ 10.651245] [] (lock_acquire) from []
> (ldsem_down_read_trylock+0x78/0x90)
> [ 10.651275] [] (ldsem_down_read_trylock) from []
> (tty_ldisc_ref+0x24/0x58)
> [ 10.651306] [] (tty_ldisc_ref) from []
> (usb_serial_handle_dcd_change+0x48/0xe8)
> [ 10.651367] [] (usb_serial_handle_dcd_change) from []
> (pl2303_read_int_callback+0x210/0x220 [pl2303])
> [ 10.651428] [] (pl2303_read_int_callback [pl2303]) from
> [] (__usb_hcd_giveback_urb+0x80/0x140)
> [ 10.651458] [] (__usb_hcd_giveback_urb) from []
> (usb_giveback_urb_bh+0x98/0xd4)
> [ 10.651489] [] (usb_giveback_urb_bh) from []
> (tasklet_hi_action+0x9c/0x108)
> [ 10.651519] [] (tasklet_hi_action) from []
> (__do_softirq+0x148/0x42c)
> [ 10.651550] [] (__do_softirq) from []
> (irq_exit+0xd8/0x114)
> [ 10.651580] [] (irq_exit) from []
> (__handle_domain_irq+0x84/0xdc)
> [ 10.651611] [] (__handle_domain_irq) from []
> (omap_intc_handle_irq+0xd8/0xe0)
> [ 10.651641] [] (omap_intc_handle_irq) from []
> (__irq_svc+0x44/0x7c)
> [ 10.651641] Exception stack(0xdf4e7f08 to 0xdf4e7f50)
> [ 10.651672] 7f00: debc0b80 df4e7f5c
> debc0b80 be8da96c
> [ 10.651702] 7f20: 0128 c000fc84 df4e6000 df4e7f94
> 0004 df4e7f50
> [ 10.651702] 7f40: c038ebc0 c038d74c 600f0013
> [ 10.651733] [] (__irq_svc) from []
> (___sys_sendmsg.part.29+0x0/0x2e0)
> [ 10.651763] [] (___sys_sendmsg.part.29) from []
> (SyS_sendmsg+0x18/0x1c)
> [ 10.651794] [] (SyS_sendmsg) from []
> (ret_fast_syscall+0x0/0x48)
> [ 10.692871] console [ttyUSB0] enabled
[1] Call tree for registering the ldsem lock class
tty_open
tty_init_dev
alloc_tty_struct
init_ldsem (macro in include/linux/tty_ldisc.h)
* the static lock_class_key is expanded here *
--
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
