linux-kernel - Re: [PATCH v3 1/2] usb: dwc3: Add a quirk to set GUCTL.SPRSCTRLTRANSEN bit.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 Jan 2022 14:35:04 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Yaqin Pan <akingchen@...o.com>
Cc:     balbi@...nel.org, devicetree@...r.kernel.org, kernel@...o.com,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        robh+dt@...nel.org
Subject: Re: [PATCH v3 1/2] usb: dwc3: Add a quirk to set
 GUCTL.SPRSCTRLTRANSEN bit.

On Fri, Dec 31, 2021 at 07:59:31PM +0800, Yaqin Pan wrote:
> 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.

Please have a list of controller that this is needed for, and add the
quirk for them only.  Don't require this to be in a DT file as that will
never be noticed.

thanks,

greg k-h