<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/linux/usb, branch v4.7</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.7</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.7'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2016-06-25T00:03:12Z</updated>
<entry>
<title>USB: EHCI: declare hostpc register as zero-length array</title>
<updated>2016-06-25T00:03:12Z</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2016-06-23T18:54:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd'/>
<id>urn:sha1:7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd</id>
<content type='text'>
The HOSTPC extension registers found in some EHCI implementations form
a variable-length array, with one element for each port.  Therefore
the hostpc field in struct ehci_regs should be declared as a
zero-length array, not a single-element array.

This fixes a problem reported by UBSAN.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Wilfried Klaebe &lt;linux-kernel@lebenslange-mailadresse.de&gt;
Tested-by: Wilfried Klaebe &lt;linux-kernel@lebenslange-mailadresse.de&gt;
CC: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: musb: Return error value from musb_mailbox</title>
<updated>2016-06-01T21:58:59Z</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2016-05-31T15:05:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=12b7db2bf8b88938798c60416172b53225207b1f'/>
<id>urn:sha1:12b7db2bf8b88938798c60416172b53225207b1f</id>
<content type='text'>
At least on n900 we have phy-twl4030-usb only generating cable
interrupts, and then have a separate USB PHY.

In order for musb to know the real cable status, we need to
clear any cached state until musb is ready. Otherwise the cable
status interrupts will get just ignored if the status does
not change from the initial state.

To do this, let's add a return value to musb_mailbox(), and
reset cached linkstat to MUSB_UNKNOWN on error. Sorry to cause
a bit of churn here, I should have added that already last time
patching musb_mailbox().

Signed-off-by: Tony Lindgren &lt;tony@atomide.com&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: gadget: Fix binding to UDC via configfs interface</title>
<updated>2016-05-31T07:02:53Z</updated>
<author>
<name>Krzysztof Opasiak</name>
<email>k.opasiak@samsung.com</email>
</author>
<published>2016-05-05T08:46:05Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f1bddbb3de60872acc2446eee97dbeb0a6d57acb'/>
<id>urn:sha1:f1bddbb3de60872acc2446eee97dbeb0a6d57acb</id>
<content type='text'>
By default user could store only valid UDC name in configfs UDC
attr by doing:

echo $UDC_NAME &gt; UDC

Commit (855ed04 "usb: gadget: udc-core: independent registration of
gadgets and gadget drivers") broke this behavior and allowed to store
any arbitrary string in UDC file and udc core was waiting for such
controller to appear.

echo "any arbitrary string here" &gt; UDC

This commit fix this by adding a flag which prevents configfs
gadget from being added to list of pending drivers if UDC with
given name has not been found.

Signed-off-by: Krzysztof Opasiak &lt;k.opasiak@samsung.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'usb-ci-v4.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next</title>
<updated>2016-05-04T17:25:58Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2016-05-04T17:25:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=792f7525ac8b9f13df8a4849b25fa4d4a2ac3400'/>
<id>urn:sha1:792f7525ac8b9f13df8a4849b25fa4d4a2ac3400</id>
<content type='text'>
Hi Greg, below are changes for chipidea and OTG FSM, no major changes.
Some for documentation, some for tiny changes, thanks.
</content>
</entry>
<entry>
<title>usb: core: hub: hub_port_init lock controller instead of bus</title>
<updated>2016-04-28T19:40:46Z</updated>
<author>
<name>Chris Bainbridge</name>
<email>chris.bainbridge@gmail.com</email>
</author>
<published>2016-04-25T12:48:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=feb26ac31a2a5cb88d86680d9a94916a6343e9e6'/>
<id>urn:sha1:feb26ac31a2a5cb88d86680d9a94916a6343e9e6</id>
<content type='text'>
The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [&lt;ffffffff81b9bab7&gt;] schedule+0x37/0x90
 [&lt;ffffffff817da7cd&gt;] usb_kill_urb+0x8d/0xd0
 [&lt;ffffffff8111e5e0&gt;] ? wake_up_atomic_t+0x30/0x30
 [&lt;ffffffff817dafbe&gt;] usb_start_wait_urb+0xbe/0x150
 [&lt;ffffffff817db10c&gt;] usb_control_msg+0xbc/0xf0
 [&lt;ffffffff817d07de&gt;] hub_port_init+0x51e/0xb70
 [&lt;ffffffff817d4697&gt;] hub_event+0x817/0x1570
 [&lt;ffffffff810f3e6f&gt;] process_one_work+0x1ff/0x620
 [&lt;ffffffff810f3dcf&gt;] ? process_one_work+0x15f/0x620
 [&lt;ffffffff810f4684&gt;] worker_thread+0x64/0x4b0
 [&lt;ffffffff810f4620&gt;] ? rescuer_thread+0x390/0x390
 [&lt;ffffffff810fa7f5&gt;] kthread+0x105/0x120
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200
 [&lt;ffffffff81ba183f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [&lt;ffffffff817fd36d&gt;] xhci_setup_device+0x53d/0xa40
 [&lt;ffffffff817fd87e&gt;] xhci_address_device+0xe/0x10
 [&lt;ffffffff817d047f&gt;] hub_port_init+0x1bf/0xb70
 [&lt;ffffffff811247ed&gt;] ? trace_hardirqs_on+0xd/0x10
 [&lt;ffffffff817d4697&gt;] hub_event+0x817/0x1570
 [&lt;ffffffff810f3e6f&gt;] process_one_work+0x1ff/0x620
 [&lt;ffffffff810f3dcf&gt;] ? process_one_work+0x15f/0x620
 [&lt;ffffffff810f4684&gt;] worker_thread+0x64/0x4b0
 [&lt;ffffffff810f4620&gt;] ? rescuer_thread+0x390/0x390
 [&lt;ffffffff810fa7f5&gt;] kthread+0x105/0x120
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200
 [&lt;ffffffff81ba183f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&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: gadget: udc: core: add usb_gadget_{un}map_request_by_dev()</title>
<updated>2016-04-19T08:11:54Z</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2016-04-18T07:53:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=679ca39fc670a5a95c2b40d2cc8cf2cee2486f7a'/>
<id>urn:sha1:679ca39fc670a5a95c2b40d2cc8cf2cee2486f7a</id>
<content type='text'>
If the following environment, the first argument of DMA API should
be set to a DMAC's device structure, not a udc controller's one.
 - A udc controller needs an external DMAC device (like a DMA Engine).
 - The external DMAC enables IOMMU.

So, this patch add usb_gadget_{un}map_request_by_dev() API to set
a DMAC's device structure by a udc controller driver.

Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>usb: otg-fsm: support multiple instances</title>
<updated>2016-04-06T09:15:03Z</updated>
<author>
<name>Roger Quadros</name>
<email>rogerq@ti.com</email>
</author>
<published>2016-03-30T09:56:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4e332df63487418ec512c3c376c07df9ab3ae035'/>
<id>urn:sha1:4e332df63487418ec512c3c376c07df9ab3ae035</id>
<content type='text'>
Move the state_changed variable into struct otg_fsm
so that we can support multiple instances.

Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Acked-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
</content>
</entry>
<entry>
<title>usb: otg-fsm: Add documentation for struct otg_fsm</title>
<updated>2016-04-06T09:14:50Z</updated>
<author>
<name>Roger Quadros</name>
<email>rogerq@ti.com</email>
</author>
<published>2016-03-30T09:56:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fa59507f720077a856c9952a31cfd45cd97ef6f9'/>
<id>urn:sha1:fa59507f720077a856c9952a31cfd45cd97ef6f9</id>
<content type='text'>
struct otg_fsm is the interface to the OTG state machine.

Document the input, output and internal state variables.
Definations are taken from Table 7-2 and Table 7-4 of
the USB OTG &amp; EH Specification Rev.2.0

Re-arrange some of the members as per use case for more
clarity.

Signed-off-by: Roger Quadros &lt;rogerq@ti.com&gt;
Acked-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Signed-off-by: Peter Chen &lt;peter.chen@nxp.com&gt;
</content>
</entry>
<entry>
<title>USB: core: let USB device know device node</title>
<updated>2016-03-05T20:05:01Z</updated>
<author>
<name>Peter Chen</name>
<email>peter.chen@freescale.com</email>
</author>
<published>2016-02-19T09:26:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=69bec725985324e79b1c47ea287815ac4ddb0521'/>
<id>urn:sha1:69bec725985324e79b1c47ea287815ac4ddb0521</id>
<content type='text'>
Although most of USB devices are hot-plug's, there are still some devices
are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
If these kinds of USB devices are multiple functions, and they can supply
other interfaces like i2c, gpios for other devices, we may need to
describe these at device tree.

In this commit, it uses "reg" in dts as physical port number to match
the phyiscal port number decided by USB core, if they are the same,
then the device node is for the device we are creating for USB core.

Signed-off-by: Peter Chen &lt;peter.chen@freescale.com&gt;
Acked-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config</title>
<updated>2016-03-04T13:14:46Z</updated>
<author>
<name>Petr Kulhavy</name>
<email>petr@barix.com</email>
</author>
<published>2016-02-24T15:27:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ead22caf8507c0533aab6b89e26776414b477b6f'/>
<id>urn:sha1:ead22caf8507c0533aab6b89e26776414b477b6f</id>
<content type='text'>
The musb_hdrc_platform_data::config was defined as a non-const pointer.
However some drivers (e.g. the ux500) set up this pointer to point to a
static structure, which is potentially dangerous. Since the musb core
uses the pointer in a read-only manner the const qualifier was added to
protect the content of the config.

Signed-off-by: Petr Kulhavy &lt;petr@barix.com&gt;
Acked-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Signed-off-by: Bin Liu &lt;b-liu@ti.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@kernel.org&gt;
</content>
</entry>
</feed>
