Commits · 3abeca998a44205cfd837fa0bf1f7c24f8294acb · Kirill Smelkov / linux

11 May, 2011 1 commit

xhci: Fix bug in control transfer cancellation. · 3abeca99

Sarah Sharp authored May 05, 2011

When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing.  The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs).  The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.

Unfortunately, there is a long-standing bug in the control transfer
completion code.  It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed.  So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.

When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel.  It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs.  Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.

It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior.  Fix this
behavior.

This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org

3abeca99

10 May, 2011 14 commits

USB: Gadget: Add Samsung S3C24XX USB High-Speed controller driver · a9df304c

Thomas Abraham authored May 07, 2011

The Samsung's S3C2416, S3C2443 and S3C2450 includes a USB High-Speed
device controller module. This driver enables support for USB high-speed
gadget functionality for the Samsung S3C24xx SoC's that include this
controller.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Alexander Neumann <alexander@bumpern.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

a9df304c

ARM: S3C2416: Add support for USB 2.0 High-Speed gadget controller · f6568045

Thomas Abraham authored May 07, 2011

Add support for USB 2.0 High-Speed gadget controller driver for Samsung's
S3C2416 processor.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

f6568045

ARM: S3C24XX: Add plaform device definition for USB High-Speed gadget controller. · 4a98f590

Thomas Abraham authored May 07, 2011

S3C2416, S3C2443 and S3C2450 includes a USB High-Speed Gadget controller module.
This patch adds the following for supporting this controller.

1. Definition for USB High-Speed controller base address.
2. Platform device instantiation.
3. Declaration for platform data structure.
4. Functionality to setup platform data for the controller.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

4a98f590

ARM: S3C2416: Add USB Phy register definitions · 0a94c6b1

Thomas Abraham authored May 07, 2011

Add register definitions required to configure the USB Phy. The definitions
for PHYCTRL, PHYPWR, URSTCON and UCLKCON registers and corresponding bit
field definitions are added.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

0a94c6b1

usb: gadget: Remove the LUN checks which are always true · 849426c3

Maxin B John authored May 08, 2011

Comparing an unsigned integer with greater than or equal to zero is
always true.  So, it is safe to remove similar checks from
'f_mass_storage.c' and 'file_storage.c'
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

849426c3

usb: fix warning in usbtest module v2 · 304b0b57

Greg Dietsche authored May 08, 2011

On amd64 unsigned is not as wide as pointer and this causes a compiler
warning. Switching to unsigned long corrects the problem.
Signed-off-by: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

304b0b57

USB: ehci-s5p : use __devinit and __devexit macros for probe and remove · 27362d46

Jingoo Han authored May 09, 2011

The __devinit and __devexit macros were added to probe and remove
functions. The macros move the probe and remove functions to the
devinit and devexit sections
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

27362d46

USB: cp210x: fix typo, Telegesys should have been Telegesis · c851e83f

Florian Fainelli authored May 10, 2011

CC: David Chalmers <david.chalmers@telegesis.com>
Reported-by: Xavier Carcelle <xavier.carcelle@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

c851e83f

usb: gadget: f_mass_storage: Make us pass USBCV MSC Compliance tests · 95ed3236

Roger Quadros authored May 09, 2011

Defer the SET_CONFIG and SET_INTERFACE control transfer's data/status
stages till we are ready to process new CBW from the host. This way we
ensure that we don't loose any CBW during MSC compliance tests and cause
lock up.
Signed-off-by: Roger Quadros <roger.quadros@nokia.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

95ed3236

usb: gadget: composite: Allow function drivers to pause control transfers · 1b9ba000

Roger Quadros authored May 09, 2011

Some USB function drivers (e.g. f_mass_storage.c) need to delay or defer the
data/status stages of standard control requests like SET_CONFIGURATION or
SET_INTERFACE till they are done with their bookkeeping and are actually ready
for accepting new commands to their interface.

They can now achieve this functionality by returning USB_GADGET_DELAYED_STATUS
in their setup handlers (e.g. set_alt()). The composite framework will then
defer completion of the control transfer by not completing the data/status stages.

This ensures that the host does not send new packets to the interface till the
function driver is ready to take them.

When the function driver that requested for USB_GADGET_DELAYED_STATUS is done
with its bookkeeping, it should signal the composite framework to continue with
the data/status stages of the control transfer. It can do so by invoking
the new API usb_composite_setup_continue(). This is where the control transfer's
data/status stages are completed and host can initiate new transfers.

The DELAYED_STATUS mechanism is currently only supported if the expected data phase
is 0 bytes (i.e. w_length == 0). Since SET_CONFIGURATION and SET_INTERFACE are the
only cases that will use this mechanism, this is not a limitation.
Signed-off-by: Roger Quadros <roger.quadros@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

1b9ba000

Merge branch 'for-usb-next' of... · 8eadef15

Greg Kroah-Hartman authored May 10, 2011

Merge branch 'for-usb-next' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next

* 'for-usb-next' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
  xHCI 1.0: Max Exit Latency Too Large Error
  xHCI 1.0: TT_THINK_TIME set
  xHCI 1.0: Block Interrupts for Isoch transfer
  xHCI 1.0: Isoch endpoint CErr field set
  xHCI 1.0: Control endpoint average TRB length field set
  xHCI 1.0: Setup Stage TRB Transfer Type flag

8eadef15

Merge branch 2.6.39-rc7 into usb-linus · 8a1629c7

Greg Kroah-Hartman authored May 10, 2011

This was needed to resolve a conflict in:
	drivers/usb/host/isp1760-hcd.c
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

8a1629c7

Linux 2.6.39-rc7 · 693d92a1
Linus Torvalds authored May 09, 2011

693d92a1

vm: fix vm_pgoff wrap in upward expansion · 42c36f63

Hugh Dickins authored May 09, 2011

Commit a626ca6a ("vm: fix vm_pgoff wrap in stack expansion") fixed
the case of an expanding mapping causing vm_pgoff wrapping when you had
downward stack expansion.  But there was another case where IA64 and
PA-RISC expand mappings: upward expansion.

This fixes that case too.
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

42c36f63

09 May, 2011 25 commits

Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 · c191f6cc

Linus Torvalds authored May 09, 2011

* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6:
  drm/i915/lvds: Only act on lid notify when the device is on
  drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"
  drm/i915: Only enable the plane after setting the fb base (pre-ILK)
  drm/i915/dp: Be paranoid in case we disable a DP before it is attached
  drm/i915: Release object along create user fb error path

c191f6cc

Don't lock guardpage if the stack is growing up · a09a79f6

Mikulas Patocka authored May 09, 2011

Linux kernel excludes guard page when performing mlock on a VMA with
down-growing stack. However, some architectures have up-growing stack
and locking the guard page should be excluded in this case too.

This patch fixes lvm2 on PA-RISC (and possibly other architectures with
up-growing stack). lvm2 calculates number of used pages when locking and
when unlocking and reports an internal error if the numbers mismatch.

[ Patch changed fairly extensively to also fix /proc/<pid>/maps for the
  grows-up case, and to move things around a bit to clean it all up and
  share the infrstructure with the /proc bits.

  Tested on ia64 that has both grow-up and grow-down segments  - Linus ]
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Tested-by: Tony Luck <tony.luck@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

a09a79f6

Merge branch 'for_linus' of... · 26822eeb

Linus Torvalds authored May 09, 2011

Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86:
  eeepc-laptop: Use ACPI handle to identify rfkill port
  [PATCH] sony-laptop: limit brightness range to DSDT provided ones
  sony-laptop: report failures on setting LCD brightness
  thinkpad-acpi: module autoloading for newer Lenovo ThinkPads.

26822eeb

xHCI 1.0: Max Exit Latency Too Large Error · 1bb73a88

Alex He authored May 05, 2011

This is a new TRB Completion Code of the xHCI spec 1.0.
Asserted by the Evalute Context Command if the proposed Max Exit Latency would
not allow the periodic endpoints of the Device Slot to be scheduled.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>