<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/usb, branch v3.5.3</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.5.3</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.5.3'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2012-06-13T20:11:39+00:00</updated>
<entry>
<title>USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2</title>
<updated>2012-06-13T20:11:39+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-06-13T15:20:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2fb8a3fa25513de8fedb38509b1f15a5bbee47b'/>
<id>urn:sha1:c2fb8a3fa25513de8fedb38509b1f15a5bbee47b</id>
<content type='text'>
This patch (as1558) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

A similar patch has already been applied as commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers).  The patch supersedes that one and reverts
it.  There are two differences:

	The old patch added the flag at the USB level; this patch
	adds it at the PCI level.

	The old patch applied to all chipsets with the same vendor,
	subsystem vendor, and product IDs; this patch makes an
	exception for a known-good system (based on DMI information).

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Dâniel Fraga &lt;fragabr@gmail.com&gt;
Tested-by: Andrey Rahmatullin &lt;wrar@wrar.name&gt;
Tested-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Reviewed-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb</title>
<updated>2012-05-22T22:50:46+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-05-22T22:50:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a481991467d38afb43c3921d5b5b59ccb61b04ba'/>
<id>urn:sha1:a481991467d38afb43c3921d5b5b59ccb61b04ba</id>
<content type='text'>
Pull USB 3.5-rc1 changes from Greg Kroah-Hartman:
 "Here is the big USB 3.5-rc1 pull request for the 3.5-rc1 merge window.

  It's touches a lot of different parts of the kernel, all USB drivers,
  due to some API cleanups (getting rid of the ancient err() macro) and
  some changes that are needed for USB 3.0 power management updates.

  There are also lots of new drivers, pimarily gadget, but others as
  well.  We deleted a staging driver, which was nice, and finally
  dropped the obsolete usbfs code, which will make Al happy to never
  have to touch that again.

  There were some build errors in the tree that linux-next found a few
  days ago, but those were fixed by the most recent changes (all were
  due to us not building with CONFIG_PM disabled.)

  Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;"

* tag 'usb-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (477 commits)
  xhci: Fix DIV_ROUND_UP compile error.
  xhci: Fix compile with CONFIG_USB_SUSPEND=n
  USB: Fix core compile with CONFIG_USB_SUSPEND=n
  brcm80211: Fix compile error for .disable_hub_initiated_lpm.
  Revert "USB: EHCI: work around bug in the Philips ISP1562 controller"
  MAINTAINERS: Add myself as maintainer to the USB PHY Layer
  USB: EHCI: fix command register configuration lost problem
  USB: Remove races in devio.c
  USB: ehci-platform: remove update_device
  USB: Disable hub-initiated LPM for comms devices.
  xhci: Add Intel U1/U2 timeout policy.
  xhci: Add infrastructure for host-specific LPM policies.
  USB: Add macros for interrupt endpoint types.
  xhci: Reserve one command for USB3 LPM disable.
  xhci: Some Evaluate Context commands must succeed.
  USB: Disable USB 3.0 LPM in critical sections.
  USB: Add support to enable/disable USB3 link states.
  USB: Allow drivers to disable hub-initiated LPM.
  USB: Calculate USB 3.0 exit latencies for LPM.
  USB: Refactor code to set LPM support flag.
  ...

Conflicts:
	arch/arm/mach-exynos/mach-nuri.c
	arch/arm/mach-exynos/mach-universal_c210.c
	drivers/net/wireless/ath/ath6kl/usb.c
</content>
</entry>
<entry>
<title>Merge tag 'for-usb-next-2012-05-18' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next</title>
<updated>2012-05-18T23:32:52+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2012-05-18T23:32:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f06b9f3ced17dfb559af2c0c5db2d68e939f06e6'/>
<id>urn:sha1:f06b9f3ced17dfb559af2c0c5db2d68e939f06e6</id>
<content type='text'>
xhci: Link PM and bug fixes for 3.5.

Hi Greg,

Here's the final Link Power Management patches, along with a couple of bug
fixes that have been sitting in my queue.  I've fixed all the comments that
Alan and Andiry had on the Link PM patches, so I think they're ready to go.

Sarah Sharp
</content>
</entry>
<entry>
<title>USB: Add macros for interrupt endpoint types.</title>
<updated>2012-05-18T22:42:02+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2012-05-08T14:44:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6538eafc7cb6b2d718d2539bef3158bfaad57468'/>
<id>urn:sha1:6538eafc7cb6b2d718d2539bef3158bfaad57468</id>
<content type='text'>
The USB 3.0 spec defines a new way of differentiating interrupt
endpoints.  The idea is that some interrupt endpoints are used for
notifications, i.e. they continually NAK the transfer until something
changes on the device.  Other interrupt endpoints are used as a way to
periodically transfer data.

The USB 3.0 endpoint descriptor uses bits 5:4 of bmAttributes for
interrupt endpoints, to define the endpoint as either a Notification
endpoint, or a Periodic endpoint.  Introduce macros to dig out that
information.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>USB: Add support to enable/disable USB3 link states.</title>
<updated>2012-05-18T22:41:58+00:00</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2012-04-25T00:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ea7e0e8e3d0f50901d335ea4178ab2aa8c88201'/>
<id>urn:sha1:1ea7e0e8e3d0f50901d335ea4178ab2aa8c88201</id>
<content type='text'>
There are various functions within the USB core that will need to
disable USB 3.0 link power states.  For example, when a USB device
driver is being bound to an interface, we need to disable USB 3.0 LPM
until we know if the driver will allow hub-initiated LPM transitions.
Another example is when the USB core is switching alternate interface
settings.  The USB 3.0 timeout values are dependent on what endpoints
are enabled, so we want to ensure that LPM is disabled until the new alt
setting is fully installed.

Multiple functions need to disable LPM, and those functions can even be
nested.  For example, usb_bind_interface() could disable LPM, and then
call into the driver probe function, which may attempt to switch to a
different alt setting.  Therefore, we need to keep a count of the number
of functions that require LPM to be disabled at any point in time.

Introduce two new USB core API calls, usb_disable_lpm() and
usb_enable_lpm().  These functions increment and decrement a new
variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
fails, it will call usb_enable_lpm() in order to balance the
lpm_disable_count.

These two new functions must be called with the bandwidth_mutex locked.
If the bandwidth_mutex is not already held by the caller, it should
instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
the bandwidth_mutex before calling usb_disable_lpm() and
usb_enable_lpm(), respectively.

Introduce a new variable (timeout) in the usb3_lpm_params structure to
keep track of the currently enabled U1/U2 timeout values.  When
usb_disable_lpm() is called, and the USB device has the U1 or U2
timeouts set to a non-zero value (meaning either device-initiated or
hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
state of the lpm_disable_count.  We want to ensure that all callers can
be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.

Otherwise the following scenario could occur:

1. Driver A is being bound to interface 1.  usb_probe_interface()
disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
even though usb_disable_lpm() fails, the probe of the driver continues,
and the bandwidth mutex is dropped.

2. Meanwhile, Driver B is being bound to interface 2.
usb_probe_interface() grabs the bandwidth mutex and calls
usb_disable_lpm().  That call should attempt to disable LPM, even
though the lpm_disable_count is set to 1 by Driver A.

For usb_enable_lpm(), we attempt to enable LPM only when the
lpm_disable_count is zero.  If some step in enabling LPM fails, it will
only have a minimal impact on power consumption, and all USB device
drivers should still work properly.  Therefore don't bother to return
any error codes.

Don't enable device-initiated LPM if the device is unconfigured.  The
USB device will only accept the U1/U2_ENABLE control transfers in the
configured state.  Do enable hub-initiated LPM in that case, since
devices are allowed to accept the LGO_Ux link commands in any state.

Don't enable or disable LPM if the device is marked as not being LPM
capable.  This can happen if:
 - the USB device doesn't have a SS BOS descriptor,
 - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
 - the xHCI host doesn't support LPM.

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Cc: Andiry Xu &lt;andiry.xu@amd.com&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>USB: gpio_vbus: wakeup support on GPIO VBUS interrupts</title>
<updated>2012-05-17T18:20:34+00:00</updated>
<author>
<name>Shinya Kuribayashi</name>
<email>shinya.kuribayashi.px@renesas.com</email>
</author>
<published>2012-05-17T11:11:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cbb062ade87b987a24aa834bbde32ad8374a4cf'/>
<id>urn:sha1:7cbb062ade87b987a24aa834bbde32ad8374a4cf</id>
<content type='text'>
We'd like to see the system waking up from the system-wide suspend
when it gets plugged-in, or the USB cable is pulled out.

Also makes it configurable via platform data 'wakeup'.

Signed-off-by: Shinya Kuribayashi &lt;shinya.kuribayashi.px@renesas.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2012-05-17T02:17:37+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2012-05-17T02:17:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=028940342a906db8da014a7603a0deddc2c323dd'/>
<id>urn:sha1:028940342a906db8da014a7603a0deddc2c323dd</id>
<content type='text'>
</content>
</entry>
<entry>
<title>USB: serial: hook up reset_resume callback</title>
<updated>2012-05-15T22:40:00+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2012-05-15T22:40:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7186364e46c3800635c283924bf25433d0a556a2'/>
<id>urn:sha1:7186364e46c3800635c283924bf25433d0a556a2</id>
<content type='text'>
The callback is now hooked up for any USB to serial driver that wants
it.  We only register the callback if any of the usb-serial structures
want it, this keeps the USB core happy.

Thanks to Alan Stern for the ideas on how to do this.

Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usbnet: fix skb traversing races during unlink(v2)</title>
<updated>2012-05-15T17:41:42+00:00</updated>
<author>
<name>Ming Lei</name>
<email>tom.leiming@gmail.com</email>
</author>
<published>2012-04-26T03:33:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5b6e9bcdeb65634b4ad604eb4536404bbfc62cfa'/>
<id>urn:sha1:5b6e9bcdeb65634b4ad604eb4536404bbfc62cfa</id>
<content type='text'>
Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock before unlink, but may
cause skb traversing races:
	- after URB is unlinked and the queue lock is released,
	the refered skb and skb-&gt;next may be moved to done queue,
	even be released
	- in skb_queue_walk_safe, the next skb is still obtained
	by next pointer of the last skb
	- so maybe trigger oops or other problems

This patch extends the usage of entry-&gt;state to describe 'start_unlink'
state, so always holding the queue(rx/tx) lock to change the state if
the referd skb is in rx or tx queue because we need to know if the
refered urb has been started unlinking in unlink_urbs.

The other part of this patch is based on Huajun's patch:
always traverse from head of the tx/rx queue to get skb which is
to be unlinked but not been started unlinking.

Signed-off-by: Huajun Li &lt;huajun.li.lee@gmail.com&gt;
Signed-off-by: Ming Lei &lt;tom.leiming@gmail.com&gt;
Cc: Oliver Neukum &lt;oneukum@suse.de&gt;
Cc: stable@kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>FunctionFS: enable multiple functions</title>
<updated>2012-05-14T16:25:44+00:00</updated>
<author>
<name>Andrzej Pietrasiewicz</name>
<email>andrzej.p@samsung.com</email>
</author>
<published>2012-05-14T13:51:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=581791f5c7a480b2cc3431af9a6e799ffd51eb5e'/>
<id>urn:sha1:581791f5c7a480b2cc3431af9a6e799ffd51eb5e</id>
<content type='text'>
Signed-off-by: Andrzej Pietrasiewicz &lt;andrzej.p@samsung.com&gt;
Signed-off-by: Kyungmin Park &lt;kyungmin.park@samsung.com&gt;
Acked-by: Michal Nazarewicz &lt;mina86@mina86.com&gt;
Cc: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
