public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yaqin Pan <akingchen@vivo.com>
To: gregkh@linuxfoundation.org
Cc: akingchen@vivo.com, balbi@kernel.org, devicetree@vger.kernel.org,
	kernel@vivo.com, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, robh+dt@kernel.org
Subject: Re: [PATCH v3 1/2] usb: dwc3: Add a quirk to set GUCTL.SPRSCTRLTRANSEN bit.
Date: Fri, 31 Dec 2021 19:59:31 +0800	[thread overview]
Message-ID: <20211231115931.20628-1-akingchen@vivo.com> (raw)
In-Reply-To: <Yc3UuSRkgiopJ5jp@kroah.com>

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


  reply	other threads:[~2021-12-31 11:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-30 13:58 [PATCH v3 0/2] usb: dwc3: Add a quirk to set GUCTL.SPRSCTRLTRANSEN bit Yaqin Pan
2021-12-30 13:58 ` [PATCH v3 1/2] " Yaqin Pan
2021-12-30 14:12   ` Greg Kroah-Hartman
2021-12-30 15:36     ` Yaqin Pan
2021-12-30 15:48       ` Greg KH
2021-12-31 11:59         ` Yaqin Pan [this message]
2022-01-03 13:35           ` Greg KH
2022-01-04 14:56             ` Yaqin Pan
2021-12-30 13:58 ` [PATCH v3 2/2] dt-bindings: usb: document snps,sprs-ctrl-trans-quirk property in dwc3 Yaqin Pan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211231115931.20628-1-akingchen@vivo.com \
    --to=akingchen@vivo.com \
    --cc=balbi@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@vivo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox