On Thu, 30 Dec 2021 16:48:09 +0100 Greg Kroah-Hartman wrote: >On Thu, Dec 30, 2021 at 11:36:12PM +0800, Yaqin Pan wrote: >> On Thu, 30 Dec 2021 15:12:27 +0100 Greg Kroah-Hartman wrote: >> >> This quirk is only for dwc3 host mode. >> >> the dwc3 controller can't emurate some devices successfully. >> >> For example, TF card reader (aaaa:8816): >> >> failed log >> >> usb 1-1: new high-speed USB device number 2 using xhci-hcd >> >> usb 1-1: device descriptor read/all, error -110 >> >> >From the usb analyzer, always return NAK in the data phase. >> >> if enable the GUCTL.SPRSCTRLTRANSEN bit. then the log is: >> >> usb 2-1: new high-speed USB device number 3 using xhci-hcd >> >> usb 2-1: New USB device found, idVendor=aaaa, >> >> idProduct=8816, bcdDevice=13.08 >> >> usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 >> >> usb 2-1: Product: MXT USB Device >> >> usb 2-1: Manufacturer: MXTronics >> >> usb 2-1: SerialNumber: 150101v01 >> >> usb 2-1: New USB device found, VID=aaaa, PID=8816 >> >> >> >> Some devices are slow in responding to Control transfers. >> >> Scheduling mulitiple transactions in one microframe/frame >> >> can cause the devices to misbehave. if this qurik is enabled, >> >> the host controller schedules transations for a Control transfer >> >> in defferent microframes/frame. >> > >> >If this is needed for all devices (i.e. you do not know what device is >> >going to be plugged in), why not just enable it for all controllers? >> >Why whould you NOT want this enabled? >> > >> >Or is this a broken hardware device and only specific host controllers >> >need this? If so, how do we know which ones need this set and which do >> >not? >> >> I think not all dwc3 controllers need this. For cell phone,customers may >> use various usb devices, we can enable this quirk to fix some compatibility >> issues. For some chip platform of qcom, i encounter this issue, not every >> platform i encounter this problem. >> >> If enabled for all controllers, it will reduce the speed of Control transfers. >> So i think it would be better for user to enable it by their own purposes. > >But how do hardware vendors know to enable this? Can we trigger off of >PCI ids? Do we need a list of quirks to show which host controllers are >broken this way? > >Burying something as basic as "reliable device connection" in a DT quirk >seems very sloppy to me. We want reliable systems, right? Yes, we want reliable systems. But i don't have a good ideal about this issue. when we meet this problem, and from the dwc-usb3 controller datasheet,we know enable one bit in dwc-usb3 controller's register can fixed this issue. Of course, i can list the host controllers that i used broken this way if needed. thanks, Yaqin pan
