<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/usb, branch v4.12.9</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.12.9</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.12.9'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2017-08-25T00:15:05Z</updated>
<entry>
<title>usb: optimize acpi companion search for usb port devices</title>
<updated>2017-08-25T00:15:05Z</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-06-02T13:36:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e2322bcce28862537c4c31684a3eeaf5a3e27c20'/>
<id>urn:sha1:e2322bcce28862537c4c31684a3eeaf5a3e27c20</id>
<content type='text'>
commit ed18c5fa945768a9bec994e786edbbbc7695acf6 upstream.

This optimization significantly reduces xhci driver load time.

In ACPI tables the acpi companion port devices are children of
the hub device. The port devices are identified by their port number
returned by the ACPI _ADR method.
_ADR 0 is reserved for the root hub device.

The current implementation to find a acpi companion port device
loops through all acpi port devices under that parent hub, evaluating
their _ADR method each time a new port device is added.

for a xHC controller with 25 ports under its roothub it
will end up invoking ACPI bytecode 625 times before all ports
are ready, making it really slow.

The _ADR values are already read and cached earler. So instead of
running the bytecode again we can check the cached _ADR value first,
and then fall back to the old way.

As one of the more significant changes, the xhci load time on
Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs

Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue</title>
<updated>2017-08-16T20:47:00Z</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2017-08-02T01:11:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0e1f0eaed6c20db41ff61e024b361ee3ec9d686c'/>
<id>urn:sha1:0e1f0eaed6c20db41ff61e024b361ee3ec9d686c</id>
<content type='text'>
commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 upstream.

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 64-bit DMA addresses, and is
then switched to using 32-bit DMA addresses.  The top 32 bits of the
address (now zero) are ignored are replaced by the 32 bits from the
*previous* programming.  Sticking with 64-bit DMA always works, but doesn't
seem very appropriate.

A PCI reset of the device restores the normal functionality, 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.

Tested-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume</title>
<updated>2017-08-16T20:46:59Z</updated>
<author>
<name>Sandeep Singh</name>
<email>sandeep.singh@amd.com</email>
</author>
<published>2017-08-04T11:05:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b23ef7b8dd7e88c2fbddb4c8b0e13366d6c23766'/>
<id>urn:sha1:b23ef7b8dd7e88c2fbddb4c8b0e13366d6c23766</id>
<content type='text'>
commit e788787ef4f9c24aafefc480a8da5f92b914e5e6 upstream.

Certain HP keyboards would keep inputting a character automatically which
is the wake-up key after S3 resume

On some AMD platforms USB host fails to respond (by holding resume-K) to
USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures
that resume is signaled for at least 20 ms (TDRSMDN), which is defined in
USB 2.0 spec. The result is that the keyboard is out of function.

In SNPS USB design, the host responds to the resume request only after
system gets back to S0 and the host gets to functional after the internal
HW restore operation that is more than 1 second after the initial resume
request from the USB device.

As a workaround for specific keyboard ID(HP Keyboards), applying port reset
after resume when the keyboard is plugged in.

Signed-off-by: Sandeep Singh &lt;Sandeep.Singh@amd.com&gt;
Signed-off-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
cc: Nehal Shah &lt;Nehal-bakulchandra.Shah@amd.com&gt;
Reviewed-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter</title>
<updated>2017-08-16T20:46:59Z</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2017-08-08T09:51:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=73e7a2dca9ccfc43bd456f97e453176d0c3152c2'/>
<id>urn:sha1:73e7a2dca9ccfc43bd456f97e453176d0c3152c2</id>
<content type='text'>
commit 7496cfe5431f21da5d27a8388c326397e3f0a5db upstream.

Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
connect to Realtek r8153.

The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
can make it work.

Since another r8153 dongle at my hand does not have the issue, so add
the quirk to the Genesys Logic hub instead.

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: core: unlink urbs from the tail of the endpoint's urb_list</title>
<updated>2017-08-16T20:46:58Z</updated>
<author>
<name>Bin Liu</name>
<email>b-liu@ti.com</email>
</author>
<published>2017-07-25T14:31:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=488f4d8048e202f9a0053c1fa16d0b17ebe575cb'/>
<id>urn:sha1:488f4d8048e202f9a0053c1fa16d0b17ebe575cb</id>
<content type='text'>
commit 2eac13624364db5b5e1666ae0bb3a4d36bc56b6e upstream.

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.

Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Bin Liu &lt;b-liu@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: Check for dropped connection before switching to full speed</title>
<updated>2017-08-16T20:46:58Z</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2017-08-01T14:41:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7ff799af2c2171605e3bcf859e8bf65b21f2fbf8'/>
<id>urn:sha1:7ff799af2c2171605e3bcf859e8bf65b21f2fbf8</id>
<content type='text'>
commit 94c43b9897abf4ea366ed4dba027494e080c7050 upstream.

Some buggy USB disk adapters disconnect and reconnect multiple times
during the enumeration procedure.  This may lead to a device
connecting at full speed instead of high speed, because when the USB
stack sees that a device isn't able to enumerate at high speed, it
tries to hand the connection over to a full-speed companion
controller.

The logic for doing this is careful to check that the device is still
connected.  But this check is inadequate if the device disconnects and
reconnects before the check is done.  The symptom is that a device
works, but much more slowly than it is capable of operating.

The situation was made worse recently by commit 22547c4cc4fe ("usb:
hub: Wait for connection to be reestablished after port reset"), which
increases the delay following a reset before a disconnect is
recognized, thus giving the device more time to reconnect.

This patch makes the check more robust.  If the device was
disconnected at any time during enumeration, we will now skip the
full-speed handover.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Zdenek Kabelac &lt;zkabelac@redhat.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: renesas_usbhs: Fix UGCTRL2 value for R-Car Gen3</title>
<updated>2017-08-16T20:46:58Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2017-08-02T04:21:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c45923eb94130287582e50d4ac12fd4f5f99c3bb'/>
<id>urn:sha1:c45923eb94130287582e50d4ac12fd4f5f99c3bb</id>
<content type='text'>
commit 2acecd58969897795cf015c9057ebd349a3fda8a upstream.

The latest HW manual (Rev.0.55) shows us this UGCTRL2.VBUSSEL bit.
If the bit sets to 1, the VBUS drive is controlled by phy related
registers (called "UCOM Registers" on the manual). Since R-Car Gen3
environment will control VBUS by phy-rcar-gen3-usb2 driver,
the UGCTRL2.VBUSSEL bit should be set to 1. So, this patch fixes
the register's value. Otherwise, even if the ID pin indicates to
peripheral, the R-Car will output USBn_PWEN to 1 when a host driver
is running.

Fixes: de18757e272d ("usb: renesas_usbhs: add R-Car Gen3 power control"
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: gadget: udc: renesas_usb3: Fix usb_gadget_giveback_request() calling</title>
<updated>2017-08-16T20:46:58Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2017-08-02T12:06:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f5324020bcef034f832291bacd0d214d02f27919'/>
<id>urn:sha1:f5324020bcef034f832291bacd0d214d02f27919</id>
<content type='text'>
commit aca5b9ebd096039657417c321a9252c696b359c2 upstream.

According to the gadget.h, a "complete" function will always be called
with interrupts disabled. However, sometimes usb3_request_done() function
is called with interrupts enabled. So, this function should be held
by spin_lock_irqsave() to disable interruption. Also, this driver has
to call spin_unlock() to avoid spinlock recursion by this driver before
calling usb_gadget_giveback_request().

Reported-by: Kazuya Mizuguchi &lt;kazuya.mizuguchi.ks@renesas.com&gt;
Tested-by: Kazuya Mizuguchi &lt;kazuya.mizuguchi.ks@renesas.com&gt;
Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069</title>
<updated>2017-08-16T20:46:56Z</updated>
<author>
<name>Alan Swanson</name>
<email>reiver@improbability.net</email>
</author>
<published>2017-07-26T11:03:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f0834df3d97e5cb7370848f668a27a75172dd70d'/>
<id>urn:sha1:f0834df3d97e5cb7370848f668a27a75172dd70d</id>
<content type='text'>
commit 89f23d51defcb94a5026d4b5da13faf4e1150a6f upstream.

Similar to commit d595259fbb7a ("usb-storage: Add ignore-residue quirk for
Initio INIC-3619") for INIC-3169 in unusual_devs.h but INIC-3069 already
present in unusual_uas.h. Both in same controller IC family.

Issue is that MakeMKV fails during key exchange with installed bluray drive
with following error:

002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED'
occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:0'

Signed-off-by: Alan Swanson &lt;reiver@improbability.net&gt;
Acked-by: Oliver Neukum &lt;oneukum@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: hcd: Mark secondary HCD as dead if the primary one died</title>
<updated>2017-08-16T20:46:54Z</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2017-07-25T21:58:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9ccd63a6fdbd9ca6b7eb90898da4809c9dfcac6d'/>
<id>urn:sha1:9ccd63a6fdbd9ca6b7eb90898da4809c9dfcac6d</id>
<content type='text'>
commit cd5a6a4fdaba150089af2afc220eae0fef74878a upstream.

Make usb_hc_died() clear the HCD_FLAG_RH_RUNNING flag for the shared
HCD and set HCD_FLAG_DEAD for it, in analogy with what is done for
the primary one.

Among other thigs, this prevents check_root_hub_suspended() from
returning -EBUSY for dead HCDs which helps to work around system
suspend issues in some situations.

This actually fixes occasional suspend failures on one of my test
machines.

Suggested-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
