2010-11-19 22:04:17

by Greg KH

[permalink] [raw]
Subject: [00/66] 2.6.36.1-stable review

This is the start of the stable review cycle for the 2.6.36.1 release.
There are 66 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let us know. If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

Responses should be made by Monday, November 22, 2010, 12:00:00 UTC
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.36.1-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h


Makefile | 2 +-
arch/arm/include/asm/kgdb.h | 5 ++-
arch/arm/kernel/kgdb.c | 2 +-
arch/arm/mach-cns3xxx/include/mach/debug-macro.S | 2 +-
arch/powerpc/kernel/ppc970-pmu.c | 2 +
arch/x86/include/asm/cpufeature.h | 2 +-
arch/x86/include/asm/io.h | 1 +
arch/x86/include/asm/mrst.h | 2 +-
arch/x86/include/asm/smp.h | 9 ++++-
arch/x86/kernel/apic/io_apic.c | 2 +
arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
arch/x86/kernel/cpu/perf_event_amd.c | 4 +-
arch/x86/kernel/crash_dump_64.c | 3 +-
arch/x86/kernel/olpc.c | 5 ++-
arch/x86/kernel/reboot.c | 2 +-
arch/x86/kernel/smp.c | 15 +++++---
arch/x86/kernel/traps.c | 1 +
arch/x86/kernel/vm86_32.c | 10 ++++-
arch/x86/kvm/svm.c | 37 +++++++++++++++++++-
arch/x86/kvm/x86.c | 4 +-
arch/x86/xen/enlighten.c | 2 +-
arch/x86/xen/smp.c | 6 ++--
drivers/ata/ahci.h | 1 +
drivers/ata/libahci.c | 18 ++++++++--
drivers/bluetooth/hci_ldisc.c | 7 ++++
drivers/char/pcmcia/synclink_cs.c | 2 +
drivers/idle/intel_idle.c | 2 +-
drivers/misc/sgi-xp/xpc_uv.c | 17 +++++++++
drivers/net/wireless/p54/eeprom.c | 4 ++-
drivers/net/wireless/p54/p54usb.c | 15 ++++++++-
drivers/platform/x86/asus-laptop.c | 6 ++--
drivers/scsi/gdth.c | 8 ++++
drivers/scsi/libsas/sas_ata.c | 1 +
drivers/scsi/pmcraid.h | 1 -
drivers/scsi/qla4xxx/ql4_nx.c | 1 +
drivers/scsi/scsi_lib.c | 3 +-
drivers/scsi/scsi_sysfs.c | 3 +-
drivers/scsi/sd.c | 15 +++++---
drivers/staging/phison/phison.c | 2 +-
drivers/staging/usbip/usbip_event.c | 16 ++-------
drivers/staging/usbip/vhci_hcd.c | 2 +
drivers/usb/core/hcd-pci.c | 4 ++-
drivers/usb/core/hub.c | 9 +++--
drivers/usb/core/message.c | 14 ++++----
drivers/usb/gadget/atmel_usba_udc.c | 3 ++
drivers/usb/gadget/composite.c | 3 +-
drivers/usb/gadget/f_acm.c | 2 +-
drivers/usb/gadget/g_ffs.c | 4 +-
drivers/usb/gadget/multi.c | 4 +-
drivers/usb/host/ohci-hcd.c | 9 ++++-
drivers/usb/host/ohci-pci.c | 18 ++++++++++
drivers/usb/host/ohci.h | 1 +
drivers/usb/host/pci-quirks.c | 18 ++++++----
drivers/usb/host/r8a66597.h | 2 +-
drivers/usb/musb/blackfin.c | 7 +++-
drivers/usb/musb/davinci.c | 2 +
drivers/usb/musb/musb_core.c | 4 --
drivers/usb/musb/omap2430.c | 1 +
drivers/usb/musb/tusb6010.c | 4 ++
drivers/usb/serial/cp210x.c | 2 +
drivers/usb/serial/ftdi_sio.c | 39 +++++++++++++++++++---
drivers/usb/serial/ftdi_sio_ids.h | 39 +++++++++++++++++++++-
drivers/usb/serial/mct_u232.c | 7 +++-
drivers/usb/serial/opticon.c | 6 ++--
drivers/usb/serial/option.c | 23 +++++++++++--
drivers/usb/serial/visor.c | 11 +++++-
fs/cifs/cifsproto.h | 3 +-
fs/cifs/dir.c | 12 +++----
fs/cifs/file.c | 4 +-
fs/nfs/direct.c | 2 +-
fs/pipe.c | 2 +-
kernel/futex.c | 31 +++++++++--------
kernel/perf_event.c | 8 ++++-
kernel/sched.c | 13 ++-----
mm/vmalloc.c | 9 +++++
net/bluetooth/l2cap.c | 4 +-
net/netfilter/xt_SECMARK.c | 2 +-
77 files changed, 420 insertions(+), 150 deletions(-)


2010-11-19 22:04:11

by Greg KH

[permalink] [raw]
Subject: [02/66] staging: usbip: Process event flags without delay

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Max Vozeler <[email protected]>

commit 584c5b7cf06194464240280483ee0376cdddbbae upstream.

The way the event handler works can cause it to delay
events until eventual wakeup for another event.

For example, on device detach (vhci):

- Write to sysfs detach file
-> usbip_event_add(VDEV_EVENT_DOWN)
-> wakeup()

#define VDEV_EVENT_DOWN (USBIP_EH_SHUTDOWN | USBIP_EH_RESET).

- Event thread wakes up and passes the event to
event_handler() to process.

- It processes and clears the USBIP_EH_SHUTDOWN
flag then returns.

- The outer event loop (event_handler_loop()) calls
wait_event_interruptible().

The processing of the second flag which is part of
VDEV_EVENT_DOWN (USBIP_EH_RESET) did not happen yet.
It is delayed until the next event.

This means the ->reset callback may not happen for
a long time (if ever), leaving the usbip port in a
weird state which prevents its reuse.

This patch changes the handler to process all flags
before waiting for another wakeup.

I have verified this change to fix a problem which
prevented reattach of a usbip device. It also helps
for socket errors which missed the RESET as well.

The delayed event processing also affects the stub
side of usbip and the error handling there.

Signed-off-by: Max Vozeler <[email protected]>
Reported-by: Marco Lancione <[email protected]>
Tested-by: Luc Jalbert <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/usbip/usbip_event.c | 16 +++-------------
1 file changed, 3 insertions(+), 13 deletions(-)

--- a/drivers/staging/usbip/usbip_event.c
+++ b/drivers/staging/usbip/usbip_event.c
@@ -38,21 +38,13 @@ static int event_handler(struct usbip_de
ud->eh_ops.shutdown(ud);

ud->event &= ~USBIP_EH_SHUTDOWN;
-
- break;
}

- /* Stop the error handler. */
- if (ud->event & USBIP_EH_BYE)
- return -1;
-
/* Reset the device. */
if (ud->event & USBIP_EH_RESET) {
ud->eh_ops.reset(ud);

ud->event &= ~USBIP_EH_RESET;
-
- break;
}

/* Mark the device as unusable. */
@@ -60,13 +52,11 @@ static int event_handler(struct usbip_de
ud->eh_ops.unusable(ud);

ud->event &= ~USBIP_EH_UNUSABLE;
-
- break;
}

- /* NOTREACHED */
- printk(KERN_ERR "%s: unknown event\n", __func__);
- return -1;
+ /* Stop the error handler. */
+ if (ud->event & USBIP_EH_BYE)
+ return -1;
}

return 0;

2010-11-19 22:04:14

by Greg KH

[permalink] [raw]
Subject: [05/66] perf_events: Fix bogus context time tracking

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Stephane Eranian <[email protected]>

commit c530ccd9a1864a44a7ff35826681229ce9f2357a upstream.

You can only call update_context_time() when the context
is active, i.e., the thread it is attached to is still running.

However, perf_event_read() can be called even when the context
is inactive, e.g., user read() the counters. The call to
update_context_time() must be conditioned on the status of
the context, otherwise, bogus time_enabled, time_running may
be returned. Here is an example on AMD64. The task program
is an example from libpfm4. The -p prints deltas every 1s.

$ task -p -e cpu_clk_unhalted sleep 5
2,266,610 cpu_clk_unhalted (0.00% scaling, ena=2,158,982, run=2,158,982)
0 cpu_clk_unhalted (0.00% scaling, ena=2,158,982, run=2,158,982)
0 cpu_clk_unhalted (0.00% scaling, ena=2,158,982, run=2,158,982)
0 cpu_clk_unhalted (0.00% scaling, ena=2,158,982, run=2,158,982)
0 cpu_clk_unhalted (0.00% scaling, ena=2,158,982, run=2,158,982)
5,242,358,071 cpu_clk_unhalted (99.95% scaling, ena=5,000,359,984, run=2,319,270)

Whereas if you don't read deltas, e.g., no call to perf_event_read() until
the process terminates:

$ task -e cpu_clk_unhalted sleep 5
2,497,783 cpu_clk_unhalted (0.00% scaling, ena=2,376,899, run=2,376,899)

Notice that time_enable, time_running are bogus in the first example
causing bogus scaling.

This patch fixes the problem, by conditionally calling update_context_time()
in perf_event_read().

Signed-off-by: Stephane Eranian <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/perf_event.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -1773,7 +1773,13 @@ static u64 perf_event_read(struct perf_e
unsigned long flags;

raw_spin_lock_irqsave(&ctx->lock, flags);
- update_context_time(ctx);
+ /*
+ * may read while context is not active
+ * (e.g., thread is blocked), in that case
+ * we cannot update context time
+ */
+ if (ctx->is_active)
+ update_context_time(ctx);
update_event_times(event);
raw_spin_unlock_irqrestore(&ctx->lock, flags);
}

2010-11-19 22:04:38

by Greg KH

[permalink] [raw]
Subject: [57/66] [SCSI] qla4xxx: fix build on PPC

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Jiri Slaby <[email protected]>

commit a6751ccb9ba85180c84135cc921eea11d83d5689 upstream.

We use read/write[bslq] but do not include linux/io.h. This causes
build failures on PPC. Include that file.

Signed-off-by: Jiri Slaby <[email protected]>
Acked-by: Vikas Chaudhary <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/qla4xxx/ql4_nx.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/scsi/qla4xxx/ql4_nx.c
+++ b/drivers/scsi/qla4xxx/ql4_nx.c
@@ -5,6 +5,7 @@
* See LICENSE.qla4xxx for copyright and licensing details.
*/
#include <linux/delay.h>
+#include <linux/io.h>
#include <linux/pci.h>
#include "ql4_def.h"
#include "ql4_glbl.h"

2010-11-19 22:04:49

by Greg KH

[permalink] [raw]
Subject: [66/66] sgi-xp: incoming XPC channel messages can come in after the channels partition structures have been torn down

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Robin Holt <[email protected]>

commit 09358972bff5ce99de496bbba97c85d417b3c054 upstream.

Under some workloads, some channel messages have been observed being
delayed on the sending side past the point where the receiving side has
been able to tear down its partition structures.

This condition is already detected in xpc_handle_activate_IRQ_uv(), but
that information is not given to xpc_handle_activate_mq_msg_uv(). As a
result, xpc_handle_activate_mq_msg_uv() assumes the structures still exist
and references them, causing a NULL-pointer deref.

Signed-off-by: Robin Holt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/misc/sgi-xp/xpc_uv.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -417,6 +417,7 @@ xpc_process_activate_IRQ_rcvd_uv(void)
static void
xpc_handle_activate_mq_msg_uv(struct xpc_partition *part,
struct xpc_activate_mq_msghdr_uv *msg_hdr,
+ int part_setup,
int *wakeup_hb_checker)
{
unsigned long irq_flags;
@@ -481,6 +482,9 @@ xpc_handle_activate_mq_msg_uv(struct xpc
case XPC_ACTIVATE_MQ_MSG_CHCTL_CLOSEREQUEST_UV: {
struct xpc_activate_mq_msg_chctl_closerequest_uv *msg;

+ if (!part_setup)
+ break;
+
msg = container_of(msg_hdr, struct
xpc_activate_mq_msg_chctl_closerequest_uv,
hdr);
@@ -497,6 +501,9 @@ xpc_handle_activate_mq_msg_uv(struct xpc
case XPC_ACTIVATE_MQ_MSG_CHCTL_CLOSEREPLY_UV: {
struct xpc_activate_mq_msg_chctl_closereply_uv *msg;

+ if (!part_setup)
+ break;
+
msg = container_of(msg_hdr, struct
xpc_activate_mq_msg_chctl_closereply_uv,
hdr);
@@ -511,6 +518,9 @@ xpc_handle_activate_mq_msg_uv(struct xpc
case XPC_ACTIVATE_MQ_MSG_CHCTL_OPENREQUEST_UV: {
struct xpc_activate_mq_msg_chctl_openrequest_uv *msg;

+ if (!part_setup)
+ break;
+
msg = container_of(msg_hdr, struct
xpc_activate_mq_msg_chctl_openrequest_uv,
hdr);
@@ -528,6 +538,9 @@ xpc_handle_activate_mq_msg_uv(struct xpc
case XPC_ACTIVATE_MQ_MSG_CHCTL_OPENREPLY_UV: {
struct xpc_activate_mq_msg_chctl_openreply_uv *msg;

+ if (!part_setup)
+ break;
+
msg = container_of(msg_hdr, struct
xpc_activate_mq_msg_chctl_openreply_uv, hdr);
args = &part->remote_openclose_args[msg->ch_number];
@@ -545,6 +558,9 @@ xpc_handle_activate_mq_msg_uv(struct xpc
case XPC_ACTIVATE_MQ_MSG_CHCTL_OPENCOMPLETE_UV: {
struct xpc_activate_mq_msg_chctl_opencomplete_uv *msg;

+ if (!part_setup)
+ break;
+
msg = container_of(msg_hdr, struct
xpc_activate_mq_msg_chctl_opencomplete_uv, hdr);
spin_lock_irqsave(&part->chctl_lock, irq_flags);
@@ -621,6 +637,7 @@ xpc_handle_activate_IRQ_uv(int irq, void

part_referenced = xpc_part_ref(part);
xpc_handle_activate_mq_msg_uv(part, msg_hdr,
+ part_referenced,
&wakeup_hb_checker);
if (part_referenced)
xpc_part_deref(part);

2010-11-19 22:05:05

by Greg KH

[permalink] [raw]
Subject: [65/66] ARM: cns3xxx: Fixup the missing second parameter to addruart macro to allow them to build.

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Mac Lin <[email protected]>

It can't be merged into Linus' tree because this file has already been
changed in incompatible ways.

Fixup the missing second parameter to addruart macro to allow them to build,
according to to commit 0e17226f7cd289504724466f4298abc9bdfca3fe.

Enabling DEBUG in head.S would cause:
rch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:1037: Error: too many positional arguments
arch/arm/boot/compressed/head.S:1055: Error: too many positional arguments

Signed-off-by: Mac Lin <[email protected]>
Acked-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mach-cns3xxx/include/mach/debug-macro.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/mach-cns3xxx/include/mach/debug-macro.S
+++ b/arch/arm/mach-cns3xxx/include/mach/debug-macro.S
@@ -10,7 +10,7 @@
* published by the Free Software Foundation.
*/

- .macro addruart,rx
+ .macro addruart,rx,rtmp
mrc p15, 0, \rx, c1, c0
tst \rx, #1 @ MMU enabled?
moveq \rx, #0x10000000

2010-11-19 22:05:27

by Greg KH

[permalink] [raw]
Subject: [64/66] kgdb,arm: fix register dump

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Rabin Vincent <[email protected]>

commit 834b2964b7ab047610da038e42d61dc8dac6339a upstream.

DBG_MAX_REG_NUM incorrectly had the number of indices in the GDB regs
array rather than the number of registers, leading to an oops when the
"rd" command is used in KDB.

Signed-off-by: Rabin Vincent <[email protected]>
Signed-off-by: Jason Wessel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/include/asm/kgdb.h | 5 +++--
arch/arm/kernel/kgdb.c | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)

--- a/arch/arm/include/asm/kgdb.h
+++ b/arch/arm/include/asm/kgdb.h
@@ -70,7 +70,8 @@ extern int kgdb_fault_expected;
#define _GP_REGS 16
#define _FP_REGS 8
#define _EXTRA_REGS 2
-#define DBG_MAX_REG_NUM (_GP_REGS + (_FP_REGS * 3) + _EXTRA_REGS)
+#define GDB_MAX_REGS (_GP_REGS + (_FP_REGS * 3) + _EXTRA_REGS)
+#define DBG_MAX_REG_NUM (_GP_REGS + _FP_REGS + _EXTRA_REGS)

#define KGDB_MAX_NO_CPUS 1
#define BUFMAX 400
@@ -93,7 +94,7 @@ extern int kgdb_fault_expected;
#define _SPT 13
#define _LR 14
#define _PC 15
-#define _CPSR (DBG_MAX_REG_NUM - 1)
+#define _CPSR (GDB_MAX_REGS - 1)

/*
* So that we can denote the end of a frame for tracing,
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -79,7 +79,7 @@ sleeping_thread_to_gdb_regs(unsigned lon
return;

/* Initialize to zero */
- for (regno = 0; regno < DBG_MAX_REG_NUM; regno++)
+ for (regno = 0; regno < GDB_MAX_REGS; regno++)
gdb_regs[regno] = 0;

/* Otherwise, we have only some registers from switch_to() */

2010-11-19 22:04:41

by Greg KH

[permalink] [raw]
Subject: [60/66] [SCSI] Fix race when removing SCSI devices

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Christof Schmitt <[email protected]>

commit 546ae796bfac6399e30da4b5af2cf7a6d0f8a4ec upstream.

Removing SCSI devices through
echo 1 > /sys/bus/scsi/devices/ ... /delete

while the FC transport class removes the SCSI target can lead to an
oops:

Unable to handle kernel pointer dereference at virtual kernel address 00000000b6815000
Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: sunrpc qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 qeth ccwgroup [last unloaded: scsi_wait_scan]
CPU: 1 Not tainted 2.6.35.5-45.x.20100924-s390xdefault #1
Process fc_wq_0 (pid: 861, task: 00000000b7331240, ksp: 00000000b735bac0)
Krnl PSW : 0704200180000000 00000000003ff6e4 (__scsi_remove_device+0x24/0xd0)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 00000000b6815000 00000000bc24a8c0
00000000003ff7c8 000000000056dbb8 0000000000000002 0000000000835d80
ffffffff00000000 0000000000001000 00000000b6815000 00000000bc24a7f0
00000000b68151a0 00000000b6815000 00000000b735bc20 00000000b735bbf8
Krnl Code: 00000000003ff6d6: a7840001 brc 8,3ff6d8
00000000003ff6da: a7fbffd8 aghi %r15,-40
00000000003ff6de: e3e0f0980024 stg %r14,152(%r15)
>00000000003ff6e4: e31021200004 lg %r1,288(%r2)
00000000003ff6ea: a71f0000 cghi %r1,0
00000000003ff6ee: a7a40011 brc 10,3ff710
00000000003ff6f2: a7390003 lghi %r3,3
00000000003ff6f6: c0e5ffffc8b1 brasl %r14,3f8858
Call Trace:
([<0000000000001000>] 0x1000)
[<00000000003ff7d2>] scsi_remove_device+0x42/0x54
[<00000000003ff8ba>] __scsi_remove_target+0xca/0xfc
[<00000000003ff99a>] __remove_child+0x3a/0x48
[<00000000003e3246>] device_for_each_child+0x72/0xbc
[<00000000003ff93a>] scsi_remove_target+0x4e/0x74
[<0000000000406586>] fc_rport_final_delete+0xb2/0x23c
[<000000000015d080>] worker_thread+0x200/0x344
[<000000000016330c>] kthread+0xa0/0xa8
[<0000000000106c1a>] kernel_thread_starter+0x6/0xc
[<0000000000106c14>] kernel_thread_starter+0x0/0xc
INFO: lockdep is turned off.
Last Breaking-Event-Address:
[<00000000003ff7cc>] scsi_remove_device+0x3c/0x54

The function __scsi_remove_target iterates through the SCSI devices on
the host, but it drops the host_lock before calling
scsi_remove_device. When the SCSI device is deleted from another
thread, the pointer to the SCSI device in scsi_remove_device can
become invalid. Fix this by getting a reference to the SCSI device
before dropping the host_lock to keep the SCSI device alive for the
call to scsi_remove_device.

Signed-off-by: Christof Schmitt <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/scsi_sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -962,10 +962,11 @@ static void __scsi_remove_target(struct
list_for_each_entry(sdev, &shost->__devices, siblings) {
if (sdev->channel != starget->channel ||
sdev->id != starget->id ||
- sdev->sdev_state == SDEV_DEL)
+ scsi_device_get(sdev))
continue;
spin_unlock_irqrestore(shost->host_lock, flags);
scsi_remove_device(sdev);
+ scsi_device_put(sdev);
spin_lock_irqsave(shost->host_lock, flags);
goto restart;
}

2010-11-19 22:04:36

by Greg KH

[permalink] [raw]
Subject: [56/66] [SCSI] libsas: fix NCQ mixing with non-NCQ

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: David Milburn <[email protected]>

commit f0ad30d3d2dc924decc0e10b1ff6dc32525a5d99 upstream.

Some cards (like mvsas) have issue troubles if non-NCQ commands are
mixed with NCQ ones. Fix this by using the libata default NCQ check
routine which waits until all NCQ commands are complete before issuing
a non-NCQ one. The impact to cards (like aic94xx) which don't need
this logic should be minimal

Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/libsas/sas_ata.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -347,6 +347,7 @@ static int sas_ata_scr_read(struct ata_l
static struct ata_port_operations sas_sata_ops = {
.phy_reset = sas_ata_phy_reset,
.post_internal_cmd = sas_ata_post_internal,
+ .qc_defer = ata_std_qc_defer,
.qc_prep = ata_noop_qc_prep,
.qc_issue = sas_ata_qc_issue,
.qc_fill_rtf = sas_ata_qc_fill_rtf,

2010-11-19 22:05:56

by Greg KH

[permalink] [raw]
Subject: [63/66] secmark: do not return early if there was no error

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Eric Paris <[email protected]>

commit 15714f7b58011cf3948cab2988abea560240c74f upstream.

Commit 4a5a5c73 attempted to pass decent error messages back to userspace for
netfilter errors. In xt_SECMARK.c however the patch screwed up and returned
on 0 (aka no error) early and didn't finish setting up secmark. This results
in a kernel BUG if you use SECMARK.

Signed-off-by: Eric Paris <[email protected]>
Acked-by: Paul Moore <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/netfilter/xt_SECMARK.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/netfilter/xt_SECMARK.c
+++ b/net/netfilter/xt_SECMARK.c
@@ -101,7 +101,7 @@ static int secmark_tg_check(const struct
switch (info->mode) {
case SECMARK_MODE_SEL:
err = checkentry_selinux(info);
- if (err <= 0)
+ if (err)
return err;
break;


2010-11-19 22:06:11

by Greg KH

[permalink] [raw]
Subject: [62/66] Fixed Regression in NFS Direct I/O path

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Steve Dickson <[email protected]>

commit 568a810d7edd58bd505222dd1c7e48895532290b upstream.

A typo, introduced by commit f11ac8db, in the nfs_direct_write()
routine causes writes with O_DIRECT set to fail with a ENOMEM error.

Found-by: Jeff Layton <[email protected]>
Signed-off-by: Steve Dickson <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/nfs/direct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -873,7 +873,7 @@ static ssize_t nfs_direct_write(struct k
dreq->inode = inode;
dreq->ctx = get_nfs_open_context(nfs_file_open_context(iocb->ki_filp));
dreq->l_ctx = nfs_get_lock_context(dreq->ctx);
- if (dreq->l_ctx != NULL)
+ if (dreq->l_ctx == NULL)
goto out_release;
if (!is_sync_kiocb(iocb))
dreq->iocb = iocb;

2010-11-19 22:06:26

by Greg KH

[permalink] [raw]
Subject: [61/66] [SCSI] Fix regressions in scsi_internal_device_block

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Mike Christie <[email protected]>

commit 986fe6c7f50974e871b8ab5a800f5310ea25b361 upstream.

Deleting a SCSI device on a blocked fc_remote_port (before
fast_io_fail_tmo fires) results in a hanging thread:

STACK:
0 schedule+1108 [0x5cac48]
1 schedule_timeout+528 [0x5cb7fc]
2 wait_for_common+266 [0x5ca6be]
3 blk_execute_rq+160 [0x354054]
4 scsi_execute+324 [0x3b7ef4]
5 scsi_execute_req+162 [0x3b80ca]
6 sd_sync_cache+138 [0x3cf662]
7 sd_shutdown+138 [0x3cf91a]
8 sd_remove+112 [0x3cfe4c]
9 __device_release_driver+124 [0x3a08b8]
10 device_release_driver+60 [0x3a0a5c]
11 bus_remove_device+266 [0x39fa76]
12 device_del+340 [0x39d818]
13 __scsi_remove_device+204 [0x3bcc48]
14 scsi_remove_device+66 [0x3bcc8e]
15 sysfs_schedule_callback_work+50 [0x260d66]
16 worker_thread+622 [0x162326]
17 kthread+160 [0x1680b0]
18 kernel_thread_starter+6 [0x10aaea]

During the delete, the SCSI device is in moved to SDEV_CANCEL. When
the FC transport class later calls scsi_target_unblock, this has no
effect, since scsi_internal_device_unblock ignores SCSI devics in this
state.

It looks like all these are regressions caused by:
5c10e63c943b4c67561ddc6bf61e01d4141f881f
[SCSI] limit state transitions in scsi_internal_device_unblock

Fix by rejecting offline and cancel in the state transition.

Signed-off-by: Christof Schmitt <[email protected]>
[jejb: Original patch by Christof Schmitt, modified by Mike Christie]
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/scsi_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2428,7 +2428,8 @@ scsi_internal_device_unblock(struct scsi
sdev->sdev_state = SDEV_RUNNING;
else if (sdev->sdev_state == SDEV_CREATED_BLOCK)
sdev->sdev_state = SDEV_CREATED;
- else
+ else if (sdev->sdev_state != SDEV_CANCEL &&
+ sdev->sdev_state != SDEV_OFFLINE)
return -EINVAL;

spin_lock_irqsave(q->queue_lock, flags);

2010-11-19 22:06:42

by Greg KH

[permalink] [raw]
Subject: [59/66] [SCSI] gdth: integer overflow in ioctl

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Dan Carpenter <[email protected]>

commit f63ae56e4e97fb12053590e41a4fa59e7daa74a4 upstream.

gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.

We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer. Then when we do the
copy_from_user(), it would result in a memory corruption.

Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/gdth.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -4175,6 +4175,14 @@ static int ioc_general(void __user *arg,
ha = gdth_find_ha(gen.ionode);
if (!ha)
return -EFAULT;
+
+ if (gen.data_len > INT_MAX)
+ return -EINVAL;
+ if (gen.sense_len > INT_MAX)
+ return -EINVAL;
+ if (gen.data_len + gen.sense_len > INT_MAX)
+ return -EINVAL;
+
if (gen.data_len + gen.sense_len != 0) {
if (!(buf = gdth_ioctl_alloc(ha, gen.data_len + gen.sense_len,
FALSE, &paddr)))

2010-11-19 22:06:43

by Greg KH

[permalink] [raw]
Subject: [58/66] [SCSI] pmcraid: remove duplicate struct member

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Anil Ravindranath <[email protected]>

commit df30e5059681ed0671c9cc6ff702fe9ca7f20042 upstream.

sense_buffer is both a direct member of struct pmcraid_cmd as well as
an indirect one via an anonymous union and struct. Fix this clash by
eliminating the direct member in favour of the anonymous struct/union
one. The name duplication apparently isn't noticed by gcc versions
earlier than 4.4

Reported-by: Andi Kleen <[email protected]>
Signed-off-by: Anil Ravindranath <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/pmcraid.h | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/scsi/pmcraid.h
+++ b/drivers/scsi/pmcraid.h
@@ -568,7 +568,6 @@ struct pmcraid_cmd {
struct pmcraid_control_block *ioa_cb;
dma_addr_t ioa_cb_bus_addr;
dma_addr_t dma_handle;
- u8 *sense_buffer;

/* pointer to mid layer structure of SCSI commands */
struct scsi_cmnd *scsi_cmd;

2010-11-19 22:04:32

by Greg KH

[permalink] [raw]
Subject: [50/66] USB: opticon: Fix long-standing bugs in opticon driver

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alon Ziv <[email protected]>

commit 97cd8dc4ca9a1a5efb2cc38758e01492e3b013e2 upstream.

The bulk-read callback had two bugs:
a) The bulk-in packet's leading two zeros were returned (and the two last
bytes truncated)
b) The wrong URB was transmitted for the second (and later) read requests,
causing further reads to return the entire packet (including leading
zeros)

Signed-off-by: Alon Ziv <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/opticon.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/usb/serial/opticon.c
+++ b/drivers/usb/serial/opticon.c
@@ -96,8 +96,8 @@ static void opticon_bulk_callback(struct
/* real data, send it to the tty layer */
tty = tty_port_tty_get(&port->port);
if (tty) {
- tty_insert_flip_string(tty, data,
- data_length);
+ tty_insert_flip_string(tty, data + 2,
+ data_length);
tty_flip_buffer_push(tty);
tty_kref_put(tty);
}
@@ -130,7 +130,7 @@ exit:
priv->bulk_address),
priv->bulk_in_buffer, priv->buffer_size,
opticon_bulk_callback, priv);
- result = usb_submit_urb(port->read_urb, GFP_ATOMIC);
+ result = usb_submit_urb(priv->bulk_read_urb, GFP_ATOMIC);
if (result)
dev_err(&port->dev,
"%s - failed resubmitting read urb, error %d\n",

2010-11-19 22:07:10

by Greg KH

[permalink] [raw]
Subject: [54/66] asus-laptop: fix gps rfkill

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Corentin Chary <[email protected]>

commit 23f45c3a76e715217f40ac397c15815c774cad7f upstream.

The GPS rfkill crappy code. The ops_data argument wasn't
set, and was totally misused. The fix have been tested
on an Asus R2H.

Signed-off-by: Corentin Chary <[email protected]>
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/platform/x86/asus-laptop.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -1065,9 +1065,9 @@ static ssize_t store_gps(struct device *
*/
static int asus_gps_rfkill_set(void *data, bool blocked)
{
- acpi_handle handle = data;
+ struct asus_laptop *asus = data;

- return asus_gps_switch(handle, !blocked);
+ return asus_gps_switch(asus, !blocked);
}

static const struct rfkill_ops asus_gps_rfkill_ops = {
@@ -1094,7 +1094,7 @@ static int asus_rfkill_init(struct asus_

asus->gps_rfkill = rfkill_alloc("asus-gps", &asus->platform_device->dev,
RFKILL_TYPE_GPS,
- &asus_gps_rfkill_ops, NULL);
+ &asus_gps_rfkill_ops, asus);
if (!asus->gps_rfkill)
return -EINVAL;


2010-11-19 22:07:07

by Greg KH

[permalink] [raw]
Subject: [55/66] [SCSI] sd name space exhaustion causes system hang

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Michael Reed <[email protected]>

commit 1a03ae0f556a931aa3747b70e44b78308f5b0590 upstream.

Following a site power outage which re-enabled all the ports on my FC
switches, my system subsequently booted with far too many luns! I had
let it run hoping it would make multi-user. It didn't. :( It hung solid
after exhausting the last sd device, sdzzz, and attempting to create sdaaaa
and beyond. I was unable to get a dump.

Discovered using a 2.6.32.13 based system.

correct this by detecting when the last index is utilized and failing
the sd probe of the device. Patch applies to scsi-misc-2.6.

Signed-off-by: Michael Reed <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/sd.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)

--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2252,11 +2252,10 @@ static void sd_probe_async(void *data, a
index = sdkp->index;
dev = &sdp->sdev_gendev;

- if (index < SD_MAX_DISKS) {
- gd->major = sd_major((index & 0xf0) >> 4);
- gd->first_minor = ((index & 0xf) << 4) | (index & 0xfff00);
- gd->minors = SD_MINORS;
- }
+ gd->major = sd_major((index & 0xf0) >> 4);
+ gd->first_minor = ((index & 0xf) << 4) | (index & 0xfff00);
+ gd->minors = SD_MINORS;
+
gd->fops = &sd_fops;
gd->private_data = &sdkp->driver;
gd->queue = sdkp->device->request_queue;
@@ -2346,6 +2345,12 @@ static int sd_probe(struct device *dev)
if (error)
goto out_put;

+ if (index >= SD_MAX_DISKS) {
+ error = -ENODEV;
+ sdev_printk(KERN_WARNING, sdp, "SCSI disk (sd) name space exhausted.\n");
+ goto out_free_index;
+ }
+
error = sd_format_disk_name("sd", index, gd->disk_name, DISK_NAME_LEN);
if (error)
goto out_free_index;

2010-11-19 22:08:07

by Greg KH

[permalink] [raw]
Subject: [52/66] USB: accept some invalid ep0-maxpacket values

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alan Stern <[email protected]>

commit 56626a72a47bf3e50875d960d6b5f17b9bee0ab2 upstream.

A few devices (such as the RCA VR5220 voice recorder) are so
non-compliant with the USB spec that they have invalid maxpacket sizes
for endpoint 0. Nevertheless, as long as we can safely use them, we
may as well do so.

This patch (as1432) softens our acceptance criterion by allowing
high-speed devices to have ep0-maxpacket sizes other than 64. A
warning is printed in the system log when this happens, and the
existing error message is clarified.

Signed-off-by: Alan Stern <[email protected]>
Reported-by: James <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/hub.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2860,13 +2860,16 @@ hub_port_init (struct usb_hub *hub, stru
else
i = udev->descriptor.bMaxPacketSize0;
if (le16_to_cpu(udev->ep0.desc.wMaxPacketSize) != i) {
- if (udev->speed != USB_SPEED_FULL ||
+ if (udev->speed == USB_SPEED_LOW ||
!(i == 8 || i == 16 || i == 32 || i == 64)) {
- dev_err(&udev->dev, "ep0 maxpacket = %d\n", i);
+ dev_err(&udev->dev, "Invalid ep0 maxpacket: %d\n", i);
retval = -EMSGSIZE;
goto fail;
}
- dev_dbg(&udev->dev, "ep0 maxpacket = %d\n", i);
+ if (udev->speed == USB_SPEED_FULL)
+ dev_dbg(&udev->dev, "ep0 maxpacket = %d\n", i);
+ else
+ dev_warn(&udev->dev, "Using ep0 maxpacket: %d\n", i);
udev->ep0.desc.wMaxPacketSize = cpu_to_le16(i);
usb_ep0_reinit(udev);
}

2010-11-19 22:08:27

by Greg KH

[permalink] [raw]
Subject: [51/66] usb: r8a66597-hcd: Change mistake of the outsw function

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Nobuhiro Iwamatsu <[email protected]>

commit ac9dfe9cdda4eb42ecaa9f13b0fee518e0b6518e upstream.

Some functions changed by 1c98347e613bf17ea2f18c9766ce0ab77f65a96d.
However, There was a change mistake of the function (outsw).

Signed-off-by: Nobuhiro Iwamatsu <[email protected]>
CC: Paul Mundt <[email protected]>
Acked-by: Yoshihiro Shimoda <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/r8a66597.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/r8a66597.h
+++ b/drivers/usb/host/r8a66597.h
@@ -227,7 +227,7 @@ static inline void r8a66597_write_fifo(s
int odd = len & 0x0001;

len = len / 2;
- ioread16_rep(fifoaddr, buf, len);
+ iowrite16_rep(fifoaddr, buf, len);
if (unlikely(odd)) {
buf = &buf[len];
iowrite8((unsigned char)*buf, fifoaddr);

2010-11-19 22:07:48

by Greg KH

[permalink] [raw]
Subject: [53/66] OHCI: work around for nVidia shutdown problem

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alan Stern <[email protected]>

commit 3df7169e73fc1d71a39cffeacc969f6840cdf52b upstream.

This patch (as1417) fixes a problem affecting some (or all) nVidia
chipsets. When the computer is shut down, the OHCI controllers
continue to power the USB buses and evidently they drive a Reset
signal out all their ports. This prevents attached devices from going
to low power. Mouse LEDs stay on, for example, which is disconcerting
for users and a drain on laptop batteries.

The fix involves leaving each OHCI controller in the OPERATIONAL state
during system shutdown rather than putting it in the RESET state.
Although this nominally means the controller is running, in fact it's
not doing very much since all the schedules are all disabled. However
there is ongoing DMA to the Host Controller Communications Area, so
the patch also disables the bus-master capability of all PCI USB
controllers after the shutdown routine runs.

The fix is applied only to nVidia-based PCI OHCI controllers, so it
shouldn't cause problems on systems using other hardware. As an added
safety measure, in case the kernel encounters one of these running
controllers during boot, the patch changes quirk_usb_handoff_ohci()
(which runs early on during PCI discovery) to reset the controller
before anything bad can happen.

Reported-by: Pali Rohár <[email protected]>
Signed-off-by: Alan Stern <[email protected]>
CC: David Brownell <[email protected]>
Tested-by: Pali Rohár <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/hcd-pci.c | 4 +++-
drivers/usb/host/ohci-hcd.c | 9 ++++++++-
drivers/usb/host/ohci-pci.c | 18 ++++++++++++++++++
drivers/usb/host/ohci.h | 1 +
drivers/usb/host/pci-quirks.c | 18 +++++++++++-------
5 files changed, 41 insertions(+), 9 deletions(-)

--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -329,8 +329,10 @@ void usb_hcd_pci_shutdown(struct pci_dev
return;

if (test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags) &&
- hcd->driver->shutdown)
+ hcd->driver->shutdown) {
hcd->driver->shutdown(hcd);
+ pci_disable_device(dev);
+ }
}
EXPORT_SYMBOL_GPL(usb_hcd_pci_shutdown);

--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -398,7 +398,14 @@ ohci_shutdown (struct usb_hcd *hcd)

ohci = hcd_to_ohci (hcd);
ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
- ohci_usb_reset (ohci);
+ ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
+
+ /* If the SHUTDOWN quirk is set, don't put the controller in RESET */
+ ohci->hc_control &= (ohci->flags & OHCI_QUIRK_SHUTDOWN ?
+ OHCI_CTRL_RWC | OHCI_CTRL_HCFS :
+ OHCI_CTRL_RWC);
+ ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
+
/* flush the writes */
(void) ohci_readl (ohci, &ohci->regs->control);
}
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -201,6 +201,20 @@ static int ohci_quirk_amd700(struct usb_
return 0;
}

+/* nVidia controllers continue to drive Reset signalling on the bus
+ * even after system shutdown, wasting power. This flag tells the
+ * shutdown routine to leave the controller OPERATIONAL instead of RESET.
+ */
+static int ohci_quirk_nvidia_shutdown(struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+
+ ohci->flags |= OHCI_QUIRK_SHUTDOWN;
+ ohci_dbg(ohci, "enabled nVidia shutdown quirk\n");
+
+ return 0;
+}
+
/*
* The hardware normally enables the A-link power management feature, which
* lets the system lower the power consumption in idle states.
@@ -332,6 +346,10 @@ static const struct pci_device_id ohci_p
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
+ {
+ PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID),
+ .driver_data = (unsigned long) ohci_quirk_nvidia_shutdown,
+ },

/* FIXME for some of the early AMD 760 southbridges, OHCI
* won't work at all. blacklist them.
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -403,6 +403,7 @@ struct ohci_hcd {
#define OHCI_QUIRK_HUB_POWER 0x100 /* distrust firmware power/oc setup */
#define OHCI_QUIRK_AMD_ISO 0x200 /* ISO transfers*/
#define OHCI_QUIRK_AMD_PREFETCH 0x400 /* pre-fetch for ISO transfer */
+#define OHCI_QUIRK_SHUTDOWN 0x800 /* nVidia power bug */
// there are also chip quirks/bugs in init logic

struct work_struct nec_work; /* Worker for NEC quirk */
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -169,6 +169,7 @@ static int __devinit mmio_resource_enabl
static void __devinit quirk_usb_handoff_ohci(struct pci_dev *pdev)
{
void __iomem *base;
+ u32 control;

if (!mmio_resource_enabled(pdev, 0))
return;
@@ -177,10 +178,14 @@ static void __devinit quirk_usb_handoff_
if (base == NULL)
return;

+ control = readl(base + OHCI_CONTROL);
+
/* On PA-RISC, PDC can leave IR set incorrectly; ignore it there. */
-#ifndef __hppa__
-{
- u32 control = readl(base + OHCI_CONTROL);
+#ifdef __hppa__
+#define OHCI_CTRL_MASK (OHCI_CTRL_RWC | OHCI_CTRL_IR)
+#else
+#define OHCI_CTRL_MASK OHCI_CTRL_RWC
+
if (control & OHCI_CTRL_IR) {
int wait_time = 500; /* arbitrary; 5 seconds */
writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
@@ -194,13 +199,12 @@ static void __devinit quirk_usb_handoff_
dev_warn(&pdev->dev, "OHCI: BIOS handoff failed"
" (BIOS bug?) %08x\n",
readl(base + OHCI_CONTROL));
-
- /* reset controller, preserving RWC */
- writel(control & OHCI_CTRL_RWC, base + OHCI_CONTROL);
}
-}
#endif

+ /* reset controller, preserving RWC (and possibly IR) */
+ writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
+
/*
* disable interrupts
*/

2010-11-19 22:04:31

by Greg KH

[permalink] [raw]
Subject: [44/66] USB: option: Add more ZTE modem USB ids

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Mauro Carvalho Chehab <[email protected]>

commit ecfa153ef616b901e86d9a051b329fcda7a6ce7b upstream.

There are lots of ZTE USB id's currently not covered by usb/serial. Adds them,
to allow those devices to work properly on Linux.

While here, put the USB ID's for 0x2002/0x2003 at the sorted order.

This patch is based on zte.c file found on MF645.

PS.: The ZTE driver is commenting the USB ID for 0x0053. It also adds, commented,
an USB ID for 0x0026.

Not sure why, but I think that 0053 is used by their devices in storage mode only.
So, I opted to keep the comment on this patch.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/option.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -622,6 +622,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0011, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0012, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0013, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0014, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF628, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0016, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0017, 0xff, 0xff, 0xff) },
@@ -633,38 +634,52 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0023, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0024, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0025, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0026, 0xff, 0xff, 0xff) },
+ /* { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0026, 0xff, 0xff, 0xff) }, */
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0028, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0029, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0030, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MF626, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0032, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0033, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0034, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0037, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0038, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0039, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0040, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0042, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0043, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0044, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0048, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0049, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0050, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0051, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0052, 0xff, 0xff, 0xff) },
+ /* { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0053, 0xff, 0xff, 0xff) }, */
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0054, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0055, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0056, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0057, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0058, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0059, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0061, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0062, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0063, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0064, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0065, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0066, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0067, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0069, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0070, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0076, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0077, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0078, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0079, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0082, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0083, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0086, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x2002, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x2003, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0087, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0104, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0105, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0106, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0108, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0113, 0xff, 0xff, 0xff) },
@@ -880,6 +895,8 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0073, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0130, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0141, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x2002, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x2003, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726, 0xff, 0xff, 0xff) },

2010-11-19 22:08:54

by Greg KH

[permalink] [raw]
Subject: [49/66] USB: visor: fix initialisation of UX50/TH55 devices

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Johan Hovold <[email protected]>

commit cfb8da8f69b81d367b766888e83ec0483a31bf01 upstream.

Fix regression introduced by commit
214916f2ec6701e1c9972f26c60b3dc37d3153c6 (USB: visor: reimplement using
generic framework) which broke initialisation of UX50/TH55 devices that
used re-mapped bulk-out endpoint addresses.

Reported-by: Robert Gadsdon <[email protected]>
Tested-by: Robert Gadsdon <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/visor.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/usb/serial/visor.c
+++ b/drivers/usb/serial/visor.c
@@ -606,6 +606,10 @@ static int treo_attach(struct usb_serial

static int clie_5_attach(struct usb_serial *serial)
{
+ struct usb_serial_port *port;
+ unsigned int pipe;
+ int j;
+
dbg("%s", __func__);

/* TH55 registers 2 ports.
@@ -621,9 +625,14 @@ static int clie_5_attach(struct usb_seri
return -1;

/* port 0 now uses the modified endpoint Address */
- serial->port[0]->bulk_out_endpointAddress =
+ port = serial->port[0];
+ port->bulk_out_endpointAddress =
serial->port[1]->bulk_out_endpointAddress;

+ pipe = usb_sndbulkpipe(serial->dev, port->bulk_out_endpointAddress);
+ for (j = 0; j < ARRAY_SIZE(port->write_urbs); ++j)
+ port->write_urbs[j]->pipe = pipe;
+
return 0;
}


2010-11-19 22:09:10

by Greg KH

[permalink] [raw]
Subject: [48/66] USB: disable endpoints after unbinding interfaces, not before

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alan Stern <[email protected]>

commit 80f0cf3947889014d3a3dc0ad60fb87cfda4b12a upstream.

This patch (as1430) fixes a bug in usbcore. When a device
configuration change occurs or a device is removed, the endpoints for
the old config should be completely disabled. However it turns out
they aren't; this is because usb_unbind_interface() calls
usb_enable_interface() or usb_set_interface() to put interfaces back
in altsetting 0, which re-enables the interfaces' endpoints.

As a result, when a device goes through a config change or is
unconfigured, the ep_in[] and ep_out[] arrays may be left holding old
pointers to usb_host_endpoint structures. If the device is
deauthorized these structures get freed, and the stale pointers cause
errors when the the device is eventually unplugged.

The solution is to disable the endpoints after unbinding the
interfaces instead of before. This isn't as large a change as it
sounds, since usb_unbind_interface() disables all the interface's
endpoints anyway before calling the driver's disconnect routine,
unless the driver claims to support "soft" unbind.

This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing
the underlying cause of the problem.

Signed-off-by: Alan Stern <[email protected]>
Tested-by: Carsten Sommer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/core/message.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1140,13 +1140,6 @@ void usb_disable_device(struct usb_devic
{
int i;

- dev_dbg(&dev->dev, "%s nuking %s URBs\n", __func__,
- skip_ep0 ? "non-ep0" : "all");
- for (i = skip_ep0; i < 16; ++i) {
- usb_disable_endpoint(dev, i, true);
- usb_disable_endpoint(dev, i + USB_DIR_IN, true);
- }
-
/* getting rid of interfaces will disconnect
* any drivers bound to them (a key side effect)
*/
@@ -1176,6 +1169,13 @@ void usb_disable_device(struct usb_devic
if (dev->state == USB_STATE_CONFIGURED)
usb_set_device_state(dev, USB_STATE_ADDRESS);
}
+
+ dev_dbg(&dev->dev, "%s nuking %s URBs\n", __func__,
+ skip_ep0 ? "non-ep0" : "all");
+ for (i = skip_ep0; i < 16; ++i) {
+ usb_disable_endpoint(dev, i, true);
+ usb_disable_endpoint(dev, i + USB_DIR_IN, true);
+ }
}

/**

2010-11-19 22:09:29

by Greg KH

[permalink] [raw]
Subject: [47/66] USB: atmel_usba_udc: force vbus_pin at -EINVAL when gpio_request failled

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

commit 969affff54702785330de553b790372e261e93f9 upstream.

to ensure gpio_is_valid return false

Signed-off-by: Nicolas Ferre <[email protected]>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/atmel_usba_udc.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -2014,6 +2014,9 @@ static int __init usba_udc_probe(struct
} else {
disable_irq(gpio_to_irq(udc->vbus_pin));
}
+ } else {
+ /* gpio_request fail so use -EINVAL for gpio_is_valid */
+ ubc->vbus_pin = -EINVAL;
}
}


2010-11-19 22:04:26

by Greg KH

[permalink] [raw]
Subject: [37/66] USB: add PID for FTDI based OpenDCC hardware

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Rainer Keller <[email protected]>

commit 99c1e4f89d1033444ce4d0c064bd2826e81c3775 upstream.

The OpenDCC project is developing a new hardware. This patch adds its
PID to the list of known FTDI devices. The PID can be found at
http://www.opendcc.de/elektronik/usb/opendcc_usb.html

Signed-off-by: Rainer Keller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -177,6 +177,7 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_SNIFFER_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_IOBOARD_PID) },
{ USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_MINI_IOBOARD_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SPROG_II) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -61,6 +61,7 @@
#define FTDI_OPENDCC_SNIFFER_PID 0xBFD9
#define FTDI_OPENDCC_THROTTLE_PID 0xBFDA
#define FTDI_OPENDCC_GATEWAY_PID 0xBFDB
+#define FTDI_OPENDCC_GBM_PID 0xBFDC

/*
* RR-CirKits LocoBuffer USB (http://www.rr-cirkits.com)

2010-11-19 22:09:55

by Greg KH

[permalink] [raw]
Subject: [43/66] USB: Change acm_iad_descriptor bFunctionProtocol to USB_CDC_ACM_PROTO_AT_V25TER

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Praveena Nadahally <[email protected]>

commit 5c8db070b4480c43394680d9dfd2ddb06b97d2ae upstream.

The protocol code is set 00 in IAD and it's set to 01 in ACM control
interface descriptor in f_acm.c file. Due to this, windows is unable to
install the modem(ACM) driver based on class-subclass-protocol matching.

This patch corrects the protocol code in ACM IAD to the same as in
acm_control_interface_desc protocol code.

Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Praveena Nadahally <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/f_acm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -111,7 +111,7 @@ acm_iad_descriptor = {
.bInterfaceCount = 2, // control + data
.bFunctionClass = USB_CLASS_COMM,
.bFunctionSubClass = USB_CDC_SUBCLASS_ACM,
- .bFunctionProtocol = USB_CDC_PROTO_NONE,
+ .bFunctionProtocol = USB_CDC_ACM_PROTO_AT_V25TER,
/* .iFunction = DYNAMIC */
};


2010-11-19 22:04:29

by Greg KH

[permalink] [raw]
Subject: [45/66] USB: cp210x: Add Renesas RX-Stick device ID

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: DJ Delorie <[email protected]>

commit 2f1136d1d08a63dcdbcd462621373f30d8dfe590 upstream.

RX610 development board by Renesas

Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x045b Hitachi, Ltd
idProduct 0x0053
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 RX-Stick
iSerial 3 0001
. . .

http://am.renesas.com/rx610stick

Signed-off-by: DJ Delorie <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -54,6 +54,7 @@ static int cp210x_carrier_raised(struct
static int debug;

static const struct usb_device_id id_table[] = {
+ { USB_DEVICE(0x045B, 0x0053) }, /* Renesas RX610 RX-Stick */
{ USB_DEVICE(0x0471, 0x066A) }, /* AKTAKOM ACE-1001 cable */
{ USB_DEVICE(0x0489, 0xE000) }, /* Pirelli Broadband S.p.A, DP-L10 SIP/GSM Mobile */
{ USB_DEVICE(0x0489, 0xE003) }, /* Pirelli Broadband S.p.A, DP-L10 SIP/GSM Mobile */

2010-11-19 22:10:19

by Greg KH

[permalink] [raw]
Subject: [42/66] usb: musb: blackfin: call gpio_free() on error path in musb_platform_init()

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Sergei Shtylyov <[email protected]>

commit 00be545e49d83485d49a598d3b7e090088934be8 upstream.

Blackfin's musb_platform_init() needs to call gpio_free() for error cleanup iff
otg_get_transceiver() call returns NULL.

Signed-off-by: Sergei Shtylyov <[email protected]>
Acked-by: Mike Frysinger <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/musb/blackfin.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -342,8 +342,10 @@ int __init musb_platform_init(struct mus

usb_nop_xceiv_register();
musb->xceiv = otg_get_transceiver();
- if (!musb->xceiv)
+ if (!musb->xceiv) {
+ gpio_free(musb->config->gpio_vrsel);
return -ENODEV;
+ }

if (ANOMALY_05000346) {
bfin_write_USB_APHY_CALIB(ANOMALY_05000346_value);

2010-11-19 22:09:41

by Greg KH

[permalink] [raw]
Subject: [46/66] USB: cp210x: Add WAGO 750-923 Service Cable device ID

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Anders Larsen <[email protected]>

commit 93ad03d60b5b18897030038234aa2ebae8234748 upstream.

The WAGO 750-923 USB Service Cable is used for configuration and firmware
updates of several industrial automation products from WAGO Kontakttechnik GmbH.

Bus 004 Device 002: ID 1be3:07a6
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1be3
idProduct 0x07a6
bcdDevice 1.00
iManufacturer 1 Silicon Labs
iProduct 2 WAGO USB Service Cable
iSerial 3 1277796751
. . .

Signed-off-by: Anders Larsen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -133,6 +133,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x17F4, 0xAAAA) }, /* Wavesense Jazz blood glucose meter */
{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
+ { USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
{ } /* Terminating Entry */
};

2010-11-19 22:10:48

by Greg KH

[permalink] [raw]
Subject: [40/66] USB: MUSB: fix kernel WARNING/oops when unloading module in OTG mode

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Sergei Shtylyov <[email protected]>

commit f405387435a85a440d1ce16f3ca36e042281643a upstream.

Since commit 461972d8a4c94bc44f11a13046041c78a7cf18dd (musb_core: don't call
musb_platform_exit() twice), unloading the driver module results in a WARNING
"kobject: '(null)' (c73de788): is not initialized, yet kobject_put() is being
called." (or even kernel oops) on e.g. DaVincis, though only in the OTG mode.
There exists dubious and unbalanced put_device() call in musb_free() which
takes place only in the OTG mode. As this commit caused musb_platform_exit()
to be called (and so unregister the NOP transceiver) before this put_device()
call, this function references already freed memory.

On the other hand, all the glue layers miss the otg_put_transceiver() call,
complementary to the otg_get_transceiver() call that they do. So, I think
the solution is to get rid of the strange put_device() call, and instead
call otg_put_transceiver() in the glue layers...

Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/musb/blackfin.c | 1 +
drivers/usb/musb/davinci.c | 2 ++
drivers/usb/musb/musb_core.c | 4 ----
drivers/usb/musb/omap2430.c | 1 +
drivers/usb/musb/tusb6010.c | 4 ++++
5 files changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -397,5 +397,6 @@ int musb_platform_exit(struct musb *musb

gpio_free(musb->config->gpio_vrsel);

+ otg_put_transceiver(musb->xceiv);
return 0;
}
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -446,6 +446,7 @@ int __init musb_platform_init(struct mus
fail:
clk_disable(musb->clock);

+ otg_put_transceiver(musb->xceiv);
usb_nop_xceiv_unregister();
return -ENODEV;
}
@@ -496,6 +497,7 @@ int musb_platform_exit(struct musb *musb

clk_disable(musb->clock);

+ otg_put_transceiver(musb->xceiv);
usb_nop_xceiv_unregister();

return 0;
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1921,10 +1921,6 @@ static void musb_free(struct musb *musb)
dma_controller_destroy(c);
}

-#ifdef CONFIG_USB_MUSB_OTG
- put_device(musb->xceiv->dev);
-#endif
-
#ifdef CONFIG_USB_MUSB_HDRC_HCD
usb_put_hcd(musb_to_hcd(musb));
#else
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -320,5 +320,6 @@ int musb_platform_exit(struct musb *musb

musb_platform_suspend(musb);

+ otg_put_transceiver(musb->xceiv);
return 0;
}
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1152,6 +1152,8 @@ done:
if (ret < 0) {
if (sync)
iounmap(sync);
+
+ otg_put_transceiver(musb->xceiv);
usb_nop_xceiv_unregister();
}
return ret;
@@ -1166,6 +1168,8 @@ int musb_platform_exit(struct musb *musb
musb->board_set_power(0);

iounmap(musb->sync_va);
+
+ otg_put_transceiver(musb->xceiv);
usb_nop_xceiv_unregister();
return 0;
}

2010-11-19 22:04:24

by Greg KH

[permalink] [raw]
Subject: [27/66] USB: mct_u232: fix broken close

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Johan Hovold <[email protected]>

commit 92ca0dc5ee022e4c0e488177e1d8865a0778c6c2 upstream.

Fix regression introduced by commit
f26788da3b342099d2b02d99ba1cb7f154d6ef7b (USB: serial: refactor generic
close) which broke driver close().

This driver uses non-standard semantics for the read urb which makes the
generic close function fail to kill it (the read urb is actually an
interrupt urb and therefore bulk_in size is zero).

Reported-by: Eric Shattow "Eprecocious" <[email protected]>
Tested-by: Eric Shattow "Eprecocious" <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/mct_u232.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -549,9 +549,12 @@ static void mct_u232_close(struct usb_se
{
dbg("%s port %d", __func__, port->number);

- usb_serial_generic_close(port);
- if (port->serial->dev)
+ if (port->serial->dev) {
+ /* shutdown our urbs */
+ usb_kill_urb(port->write_urb);
+ usb_kill_urb(port->read_urb);
usb_kill_urb(port->interrupt_in_urb);
+ }
} /* mct_u232_close */



2010-11-19 22:10:51

by Greg KH

[permalink] [raw]
Subject: [41/66] usb: musb: blackfin: call usb_nop_xceiv_unregister() in musb_platform_exit()

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Sergei Shtylyov <[email protected]>

commit 3daad24d6c72affdd40e8b6a75c87d3c175880b6 upstream.

Blackfin's musb_platform_exit() forgets to call usb_nop_xceiv_unregister().
While fixing this, also remove the unneeded blank line there.

Signed-off-by: Sergei Shtylyov <[email protected]>
Acked-by: Mike Frysinger <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/musb/blackfin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -394,9 +394,9 @@ int __init musb_platform_init(struct mus

int musb_platform_exit(struct musb *musb)
{
-
gpio_free(musb->config->gpio_vrsel);

otg_put_transceiver(musb->xceiv);
+ usb_nop_xceiv_unregister();
return 0;
}

2010-11-19 22:11:17

by Greg KH

[permalink] [raw]
Subject: [39/66] USB: ftdi_sio: add device ids for ScienceScope

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Greg Kroah-Hartman <[email protected]>

commit 0f266abd70cd83571eca019f764b5f1992da7361 upstream.

This adds the requested device ids to the ftdi_sio driver.

Reported-by: Ewan Bingham <[email protected]>
Cc: Kuba Ober <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/ftdi_sio.c | 3 +++
drivers/usb/serial/ftdi_sio_ids.h | 5 +++++
2 files changed, 8 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -791,6 +791,9 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_CHAMSYS_MAXI_WING_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CHAMSYS_MEDIA_WING_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CHAMSYS_WING_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_SCIENCESCOPE_LOGBOOKML_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_SCIENCESCOPE_LS_LOGBOOK_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_SCIENCESCOPE_HS_LOGBOOK_PID) },
{ }, /* Optional parameter entry */
{ } /* Terminating entry */
};
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1095,3 +1095,8 @@
* Accesio USB Data Acquisition products (http://www.accesio.com/)
*/
#define ACCESIO_COM4SM_PID 0xD578
+
+/* http://www.sciencescope.co.uk educational dataloggers */
+#define FTDI_SCIENCESCOPE_LOGBOOKML_PID 0xFF18
+#define FTDI_SCIENCESCOPE_LS_LOGBOOK_PID 0xFF1C
+#define FTDI_SCIENCESCOPE_HS_LOGBOOK_PID 0xFF1D

2010-11-19 22:11:19

by Greg KH

[permalink] [raw]
Subject: [38/66] USB: ftdi_sio: new VID/PIDs for various Papouch devices

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Daniel Suchy <[email protected]>

commit 59c6ccd9f9aecfa59c99ceba6d4d34b180547a05 upstream.

This patch for FTDI USB serial driver ads new VID/PIDs used on various
devices manufactured by Papouch (http://www.papouch.com). These devices
have their own VID/PID, although they're using standard FTDI chip. In
ftdi_sio.c, I also made small cleanup to have declarations for all
Papouch devices together.

Signed-off-by: Daniel Suchy <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/ftdi_sio.c | 30 +++++++++++++++++++++++++++++-
drivers/usb/serial/ftdi_sio_ids.h | 27 ++++++++++++++++++++++++++-
2 files changed, 55 insertions(+), 2 deletions(-)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -675,7 +675,6 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, FTDI_RRCIRKITS_LOCOBUFFER_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ASK_RDR400_PID) },
{ USB_DEVICE(ICOM_ID1_VID, ICOM_ID1_PID) },
- { USB_DEVICE(PAPOUCH_VID, PAPOUCH_TMU_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ACG_HFDUAL_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_YEI_SERVOCENTER31_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_THORLABS_PID) },
@@ -716,8 +715,37 @@ static struct usb_device_id id_table_com
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) },
{ USB_DEVICE(FTDI_VID, FTDI_REU_TINY_PID) },
+
+ /* Papouch devices based on FTDI chip */
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB485_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_AP485_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB422_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB485_2_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_AP485_2_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB422_2_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB485S_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB485C_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_LEC_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SB232_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_TMU_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_IRAMP_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_DRAK5_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO8x8_PID) },
{ USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO4x4_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO2x2_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO10x1_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO30x3_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO60x3_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO2x16_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_QUIDO3x32_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_DRAK6_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_UPSUSB_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_MU_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_SIMUKEY_PID) },
{ USB_DEVICE(PAPOUCH_VID, PAPOUCH_AD4USB_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_GMUX_PID) },
+ { USB_DEVICE(PAPOUCH_VID, PAPOUCH_GMSR_PID) },
+
{ USB_DEVICE(FTDI_VID, FTDI_DOMINTELL_DGQG_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_DOMINTELL_DUSB_PID) },
{ USB_DEVICE(ALTI2_VID, ALTI2_N3_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1023,9 +1023,34 @@
*/

#define PAPOUCH_VID 0x5050 /* Vendor ID */
+#define PAPOUCH_SB485_PID 0x0100 /* Papouch SB485 USB-485/422 Converter */
+#define PAPOUCH_AP485_PID 0x0101 /* AP485 USB-RS485 Converter */
+#define PAPOUCH_SB422_PID 0x0102 /* Papouch SB422 USB-RS422 Converter */
+#define PAPOUCH_SB485_2_PID 0x0103 /* Papouch SB485 USB-485/422 Converter */
+#define PAPOUCH_AP485_2_PID 0x0104 /* AP485 USB-RS485 Converter */
+#define PAPOUCH_SB422_2_PID 0x0105 /* Papouch SB422 USB-RS422 Converter */
+#define PAPOUCH_SB485S_PID 0x0106 /* Papouch SB485S USB-485/422 Converter */
+#define PAPOUCH_SB485C_PID 0x0107 /* Papouch SB485C USB-485/422 Converter */
+#define PAPOUCH_LEC_PID 0x0300 /* LEC USB Converter */
+#define PAPOUCH_SB232_PID 0x0301 /* Papouch SB232 USB-RS232 Converter */
#define PAPOUCH_TMU_PID 0x0400 /* TMU USB Thermometer */
-#define PAPOUCH_QUIDO4x4_PID 0x0900 /* Quido 4/4 Module */
+#define PAPOUCH_IRAMP_PID 0x0500 /* Papouch IRAmp Duplex */
+#define PAPOUCH_DRAK5_PID 0x0700 /* Papouch DRAK5 */
+#define PAPOUCH_QUIDO8x8_PID 0x0800 /* Papouch Quido 8/8 Module */
+#define PAPOUCH_QUIDO4x4_PID 0x0900 /* Papouch Quido 4/4 Module */
+#define PAPOUCH_QUIDO2x2_PID 0x0a00 /* Papouch Quido 2/2 Module */
+#define PAPOUCH_QUIDO10x1_PID 0x0b00 /* Papouch Quido 10/1 Module */
+#define PAPOUCH_QUIDO30x3_PID 0x0c00 /* Papouch Quido 30/3 Module */
+#define PAPOUCH_QUIDO60x3_PID 0x0d00 /* Papouch Quido 60(100)/3 Module */
+#define PAPOUCH_QUIDO2x16_PID 0x0e00 /* Papouch Quido 2/16 Module */
+#define PAPOUCH_QUIDO3x32_PID 0x0f00 /* Papouch Quido 3/32 Module */
+#define PAPOUCH_DRAK6_PID 0x1000 /* Papouch DRAK6 */
+#define PAPOUCH_UPSUSB_PID 0x8000 /* Papouch UPS-USB adapter */
+#define PAPOUCH_MU_PID 0x8001 /* MU controller */
+#define PAPOUCH_SIMUKEY_PID 0x8002 /* Papouch SimuKey */
#define PAPOUCH_AD4USB_PID 0x8003 /* AD4USB Measurement Module */
+#define PAPOUCH_GMUX_PID 0x8004 /* Papouch GOLIATH MUX */
+#define PAPOUCH_GMSR_PID 0x8005 /* Papouch GOLIATH MSR */

/*
* Marvell SheevaPlug

2010-11-19 22:11:45

by Greg KH

[permalink] [raw]
Subject: [36/66] USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes"

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Johan Hovold <[email protected]>

commit 677aeafe19e88c282af74564048243ccabb1c590 upstream.

This reverts commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd.

RTS and DTR should not be modified based on CRTSCTS when calling
set_termios.

Modem control lines are raised at port open by the tty layer and should stay
raised regardless of whether hardware flow control is enabled or not.

This is in conformance with the way serial ports work today and many
applications depend on this behaviour to be able to talk to hardware
implementing hardware flow control (without the applications actually using
it).

Hardware which expects different behaviour on these lines can always
use TIOCMSET/TIOCMBI[SC] after port open to change them.

Reported-by: Daniel Mack <[email protected]>
Reported-by: Dave Mielke <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/ftdi_sio.c | 4 ----
1 file changed, 4 deletions(-)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2029,8 +2029,6 @@ static void ftdi_set_termios(struct tty_
"urb failed to set to rts/cts flow control\n");
}

- /* raise DTR/RTS */
- set_mctrl(port, TIOCM_DTR | TIOCM_RTS);
} else {
/*
* Xon/Xoff code
@@ -2078,8 +2076,6 @@ static void ftdi_set_termios(struct tty_
}
}

- /* lower DTR/RTS */
- clear_mctrl(port, TIOCM_DTR | TIOCM_RTS);
}
return;
}

2010-11-19 22:12:35

by Greg KH

[permalink] [raw]
Subject: [35/66] USB: ftdi_sio: Add PID for accesio products

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Rich Mattes <[email protected]>

commit 3126d8236ca6f68eb8292c6af22c2e59afbeef24 upstream.

Adds support for Accesio USB to Serial adapters, which are built around
FTDI FT232 UARTs. Tested with the Accesio USB-COM-4SM.

Signed-off-by: Rich Mattes <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++++++
2 files changed, 7 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -751,6 +751,7 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_SH4_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, SEGWAY_RMP200_PID) },
+ { USB_DEVICE(FTDI_VID, ACCESIO_COM4SM_PID) },
{ USB_DEVICE(IONICS_VID, IONICS_PLUGCOMPUTER_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_CHAMSYS_24_MASTER_WING_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1063,3 +1063,9 @@
* Submitted by John G. Rogers
*/
#define SEGWAY_RMP200_PID 0xe729
+
+
+/*
+ * Accesio USB Data Acquisition products (http://www.accesio.com/)
+ */
+#define ACCESIO_COM4SM_PID 0xD578

2010-11-19 22:04:21

by Greg KH

[permalink] [raw]
Subject: [22/66] x86, intr-remap: Set redirection hint in the IRTE

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Suresh Siddha <[email protected]>

commit 75e3cfbed6f71a8f151dc6e413b6ce3c390030cb upstream.

Currently the redirection hint in the interrupt-remapping table entry
is set to 0, which means the remapped interrupt is directed to the
processors listed in the destination. So in logical flat mode
in the presence of intr-remapping, this results in a single
interrupt multi-casted to multiple cpu's as specified by the destination
bit mask. But what we really want is to send that interrupt to one of the cpus
based on the lowest priority delivery mode.

Set the redirection hint in the IRTE to '1' to indicate that we want
the remapped interrupt to be directed to only one of the processors
listed in the destination.

This fixes the issue of same interrupt getting delivered to multiple cpu's
in the logical flat mode in the presence of interrupt-remapping. While
there is no functional issue observed with this behavior, this will
impact performance of such configurations (<=8 cpu's using logical flat
mode in the presence of interrupt-remapping)

Signed-off-by: Suresh Siddha <[email protected]>
LKML-Reference: <[email protected]>
Cc: Weidong Han <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/apic/io_apic.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1397,6 +1397,7 @@ int setup_ioapic_entry(int apic_id, int
irte.dlvry_mode = apic->irq_delivery_mode;
irte.vector = vector;
irte.dest_id = IRTE_DEST(destination);
+ irte.redir_hint = 1;

/* Set source-id of interrupt request */
set_ioapic_sid(&irte, apic_id);
@@ -3348,6 +3349,7 @@ static int msi_compose_msg(struct pci_de
irte.dlvry_mode = apic->irq_delivery_mode;
irte.vector = cfg->vector;
irte.dest_id = IRTE_DEST(dest);
+ irte.redir_hint = 1;

/* Set source-id of interrupt request */
if (pdev)

2010-11-19 22:12:48

by Greg KH

[permalink] [raw]
Subject: [34/66] USB: gadget: g_multi: fixed vendor and product ID

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Michal Nazarewicz <[email protected]>

commit 1c6529e92b7682573837e9c9eb7b5ba7a8216a88 upstream.

This patch fixes the vendor and product ID the gadget uses
by replacing the temporary IDs that were used during
development (which should never get into mainline) with
proper IDs.

Signed-off-by: Michal Nazarewicz <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/multi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/gadget/multi.c
+++ b/drivers/usb/gadget/multi.c
@@ -74,8 +74,8 @@ MODULE_LICENSE("GPL");

/***************************** Device Descriptor ****************************/

-#define MULTI_VENDOR_NUM 0x0525 /* XXX NetChip */
-#define MULTI_PRODUCT_NUM 0xa4ab /* XXX */
+#define MULTI_VENDOR_NUM 0x1d6b /* Linux Foundation */
+#define MULTI_PRODUCT_NUM 0x0104 /* Multifunction Composite Gadget */


enum {

2010-11-19 22:13:00

by Greg KH

[permalink] [raw]
Subject: [33/66] USB: gadget: g_ffs: fixed vendor and product ID

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Michal Nazarewicz <[email protected]>

commit ba0534be935d7b24e5fdd6f82c443ee75abc9149 upstream.

This patch fixes the vendor and product ID the gadget uses
by replacing the temporary IDs that were used during
development (which should never get into mainline) with
proper IDs.

Signed-off-by: Michal Nazarewicz <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/g_ffs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/usb/gadget/g_ffs.c
+++ b/drivers/usb/gadget/g_ffs.c
@@ -53,8 +53,8 @@ MODULE_AUTHOR("Michal Nazarewicz");
MODULE_LICENSE("GPL");


-static unsigned short gfs_vendor_id = 0x0525; /* XXX NetChip */
-static unsigned short gfs_product_id = 0xa4ac; /* XXX */
+static unsigned short gfs_vendor_id = 0x1d6b; /* Linux Foundation */
+static unsigned short gfs_product_id = 0x0105; /* FunctionFS Gadget */

static struct usb_device_descriptor gfs_dev_desc = {
.bLength = sizeof gfs_dev_desc,

2010-11-19 22:04:19

by Greg KH

[permalink] [raw]
Subject: [18/66] x86, mrst: A function in a header file needs to be marked "inline"

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: H. Peter Anvin <[email protected]>

commit 55572b293b3a5929e8c54bc91d14ae6264186bf6 upstream.

A function in a header file needs to be explicitly marked "inline", or
gcc will complain if it is not used.

Signed-off-by: H. Peter Anvin <[email protected]>
Cc: Jacob Pan <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/asm/mrst.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/include/asm/mrst.h
+++ b/arch/x86/include/asm/mrst.h
@@ -26,7 +26,7 @@ enum mrst_cpu_type {
};

extern enum mrst_cpu_type __mrst_cpu_chip;
-static enum mrst_cpu_type mrst_identify_cpu(void)
+static inline enum mrst_cpu_type mrst_identify_cpu(void)
{
return __mrst_cpu_chip;
}

2010-11-19 22:13:20

by Greg KH

[permalink] [raw]
Subject: [32/66] usb gadget: composite: prevent OOPS for non-standard control request

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Roger Quadros <[email protected]>

commit 5c836e4d583701a5eecb288b5f131da39115f5ec upstream.

The composite gadget will OOPS if the host sends a control request
targetted to an interface of an un-configured composite device. This patch
prevents this.

The OOPS was observed during WHQL USB CV tests. With this patch, the device
STALLs as per requirement.

Failing test case: From host do the following. I used libusb-1.0

1) Set configuration to zero.
libusb_control_transfer(device_handle,
0, /* standard OUT */
0x9, /* setConfiguration */
0, 0, NULL, 0, 0);

2) Query current configuratioan.
libusb_control_transfer(device_handle,
0x80, /* standard IN*/
0x8, /* getConfiguration */
0, 0, data, 1, 0);

3) Send the non-standard ctrl transfer targetted to interface
libusb_control_transfer(device_handle,
0x81, /* standard IN to interface*/
0x6, /* getDescriptor */
0x2300, 0, data, 0x12, 0);

Signed-off-by: Roger Quadros <[email protected]>
Cc: David Brownell <[email protected]>
Cc: Michal Nazarewicz <[email protected]>
Cc: Robert Lukassen <[email protected]>
Cc: Kyungmin Park <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/composite.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -901,7 +901,8 @@ unknown:
*/
switch (ctrl->bRequestType & USB_RECIP_MASK) {
case USB_RECIP_INTERFACE:
- f = cdev->config->interface[intf];
+ if (cdev->config)
+ f = cdev->config->interface[intf];
break;

case USB_RECIP_ENDPOINT:

2010-11-19 22:14:07

by Greg KH

[permalink] [raw]
Subject: [29/66] p54usb: fix off-by-one on !CONFIG_PM

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Christian Lamparter <[email protected]>

commit 11791a6f7534906b4a01ffb54ba0b02ca39398ef upstream.

The ISL3887 chip needs a USB reset, whenever the
usb-frontend module "p54usb" is reloaded.

This patch fixes an off-by-one bug, if the user
is running a kernel without the CONFIG_PM option
set and for some reason (e.g.: compat-wireless)
wants to switch between different p54usb modules.

Signed-off-by: Christian Lamparter <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/p54/p54usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -930,8 +930,8 @@ static int __devinit p54u_probe(struct u
#ifdef CONFIG_PM
/* ISL3887 needs a full reset on resume */
udev->reset_resume = 1;
+#endif /* CONFIG_PM */
err = p54u_device_reset(dev);
-#endif

priv->hw_type = P54U_3887;
dev->extra_tx_headroom += sizeof(struct lm87_tx_hdr);

2010-11-19 22:14:05

by Greg KH

[permalink] [raw]
Subject: [30/66] p54usb: add five more USBIDs

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Christian Lamparter <[email protected]>

commit 1a92795dac419128eb511dce30a6aad672064b88 upstream.

Source:
http://www.wikidevi.com/wiki/Intersil/p54/usb/windows

Signed-off-by: Christian Lamparter <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/p54/p54usb.c | 13 +++++++++++++
1 file changed, 13 insertions(+)

--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -33,8 +33,17 @@ MODULE_ALIAS("prism54usb");
MODULE_FIRMWARE("isl3886usb");
MODULE_FIRMWARE("isl3887usb");

+/*
+ * Note:
+ *
+ * Always update our wiki's device list (located at:
+ * http://wireless.kernel.org/en/users/Drivers/p54/devices ),
+ * whenever you add a new device.
+ */
+
static struct usb_device_id p54u_table[] __devinitdata = {
/* Version 1 devices (pci chip + net2280) */
+ {USB_DEVICE(0x045e, 0x00c2)}, /* Microsoft MN-710 */
{USB_DEVICE(0x0506, 0x0a11)}, /* 3COM 3CRWE254G72 */
{USB_DEVICE(0x06b9, 0x0120)}, /* Thomson SpeedTouch 120g */
{USB_DEVICE(0x0707, 0xee06)}, /* SMC 2862W-G */
@@ -47,7 +56,9 @@ static struct usb_device_id p54u_table[]
{USB_DEVICE(0x0846, 0x4220)}, /* Netgear WG111 */
{USB_DEVICE(0x09aa, 0x1000)}, /* Spinnaker Proto board */
{USB_DEVICE(0x0cde, 0x0006)}, /* Medion 40900, Roper Europe */
+ {USB_DEVICE(0x107b, 0x55f2)}, /* Gateway WGU-210 (Gemtek) */
{USB_DEVICE(0x124a, 0x4023)}, /* Shuttle PN15, Airvast WM168g, IOGear GWU513 */
+ {USB_DEVICE(0x1630, 0x0005)}, /* 2Wire 802.11g USB (v1) / Z-Com */
{USB_DEVICE(0x1915, 0x2234)}, /* Linksys WUSB54G OEM */
{USB_DEVICE(0x1915, 0x2235)}, /* Linksys WUSB54G Portable OEM */
{USB_DEVICE(0x2001, 0x3701)}, /* DLink DWL-G120 Spinnaker */
@@ -60,6 +71,7 @@ static struct usb_device_id p54u_table[]
{USB_DEVICE(0x050d, 0x7050)}, /* Belkin F5D7050 ver 1000 */
{USB_DEVICE(0x0572, 0x2000)}, /* Cohiba Proto board */
{USB_DEVICE(0x0572, 0x2002)}, /* Cohiba Proto board */
+ {USB_DEVICE(0x06a9, 0x000e)}, /* Westell 802.11g USB (A90-211WG-01) */
{USB_DEVICE(0x06b9, 0x0121)}, /* Thomson SpeedTouch 121g */
{USB_DEVICE(0x0707, 0xee13)}, /* SMC 2862W-G version 2 */
{USB_DEVICE(0x083a, 0x4521)}, /* Siemens Gigaset USB Adapter 54 version 2 */
@@ -80,6 +92,7 @@ static struct usb_device_id p54u_table[]
{USB_DEVICE(0x13B1, 0x000C)}, /* Linksys WUSB54AG */
{USB_DEVICE(0x1413, 0x5400)}, /* Telsey 802.11g USB2.0 Adapter */
{USB_DEVICE(0x1435, 0x0427)}, /* Inventel UR054G */
+ {USB_DEVICE(0x1668, 0x1050)}, /* Actiontec 802UIG-1 */
{USB_DEVICE(0x2001, 0x3704)}, /* DLink DWL-G122 rev A2 */
{USB_DEVICE(0x413c, 0x5513)}, /* Dell WLA3310 USB Wireless Adapter */
{USB_DEVICE(0x413c, 0x8102)}, /* Spinnaker DUT */

2010-11-19 22:14:36

by Greg KH

[permalink] [raw]
Subject: [28/66] pipe: fix failure to return error code on ->confirm()

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Nicolas Kaiser <[email protected]>

commit e5953cbdff26f7cbae7eff30cd9b18c4e19b7594 upstream.

The arguments were transposed, we want to assign the error code to
'ret', which is being returned.

Signed-off-by: Nicolas Kaiser <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/pipe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -382,7 +382,7 @@ pipe_read(struct kiocb *iocb, const stru
error = ops->confirm(pipe, buf);
if (error) {
if (!ret)
- error = ret;
+ ret = error;
break;
}


2010-11-19 22:14:53

by Greg KH

[permalink] [raw]
Subject: [26/66] KVM: SVM: Restore correct registers after sel_cr0 intercept emulation

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Joerg Roedel <[email protected]>

commit cda0008299a06f0d7218c6037c3c02d7a865e954 upstream.

This patch implements restoring of the correct rip, rsp, and
rax after the svm emulation in KVM injected a selective_cr0
write intercept into the guest hypervisor. The problem was
that the vmexit is emulated in the instruction emulation
which later commits the registers right after the write-cr0
instruction. So the l1 guest will continue to run with the
l2 rip, rsp and rax resulting in unpredictable behavior.

This patch is not the final word, it is just an easy patch
to fix the issue. The real fix will be done when the
instruction emulator is made aware of nested virtualization.
Until this is done this patch fixes the issue and provides
an easy way to fix this in -stable too.

Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Marcelo Tosatti <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/svm.c | 33 +++++++++++++++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -88,6 +88,14 @@ struct nested_state {
/* A VMEXIT is required but not yet emulated */
bool exit_required;

+ /*
+ * If we vmexit during an instruction emulation we need this to restore
+ * the l1 guest rip after the emulation
+ */
+ unsigned long vmexit_rip;
+ unsigned long vmexit_rsp;
+ unsigned long vmexit_rax;
+
/* cache for intercepts of the guest */
u16 intercept_cr_read;
u16 intercept_cr_write;
@@ -1206,8 +1214,12 @@ static void svm_set_cr0(struct kvm_vcpu
if (old == new) {
/* cr0 write with ts and mp unchanged */
svm->vmcb->control.exit_code = SVM_EXIT_CR0_SEL_WRITE;
- if (nested_svm_exit_handled(svm) == NESTED_EXIT_DONE)
+ if (nested_svm_exit_handled(svm) == NESTED_EXIT_DONE) {
+ svm->nested.vmexit_rip = kvm_rip_read(vcpu);
+ svm->nested.vmexit_rsp = kvm_register_read(vcpu, VCPU_REGS_RSP);
+ svm->nested.vmexit_rax = kvm_register_read(vcpu, VCPU_REGS_RAX);
return;
+ }
}
}

@@ -2399,6 +2411,23 @@ static int emulate_on_interception(struc
return emulate_instruction(&svm->vcpu, 0, 0, 0) == EMULATE_DONE;
}

+static int cr0_write_interception(struct vcpu_svm *svm)
+{
+ struct kvm_vcpu *vcpu = &svm->vcpu;
+ int r;
+
+ r = emulate_instruction(&svm->vcpu, 0, 0, 0);
+
+ if (svm->nested.vmexit_rip) {
+ kvm_register_write(vcpu, VCPU_REGS_RIP, svm->nested.vmexit_rip);
+ kvm_register_write(vcpu, VCPU_REGS_RSP, svm->nested.vmexit_rsp);
+ kvm_register_write(vcpu, VCPU_REGS_RAX, svm->nested.vmexit_rax);
+ svm->nested.vmexit_rip = 0;
+ }
+
+ return r == EMULATE_DONE;
+}
+
static int cr8_write_interception(struct vcpu_svm *svm)
{
struct kvm_run *kvm_run = svm->vcpu.run;
@@ -2672,7 +2701,7 @@ static int (*svm_exit_handlers[])(struct
[SVM_EXIT_READ_CR4] = emulate_on_interception,
[SVM_EXIT_READ_CR8] = emulate_on_interception,
[SVM_EXIT_CR0_SEL_WRITE] = emulate_on_interception,
- [SVM_EXIT_WRITE_CR0] = emulate_on_interception,
+ [SVM_EXIT_WRITE_CR0] = cr0_write_interception,
[SVM_EXIT_WRITE_CR3] = emulate_on_interception,
[SVM_EXIT_WRITE_CR4] = emulate_on_interception,
[SVM_EXIT_WRITE_CR8] = cr8_write_interception,

2010-11-19 22:04:15

by Greg KH

[permalink] [raw]
Subject: [13/66] cifs: fix broken oplock handling

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Suresh Jayaraman <[email protected]>

commit aa91c7e4ab9b0842b7d7a7cbf8cca18b20df89b5 upstream.

cifs_new_fileinfo() does not use the 'oplock' value from the callers. Instead,
it sets it to REQ_OPLOCK which seems wrong. We should be using the oplock value
obtained from the Server to set the inode's clientCanCacheAll or
clientCanCacheRead flags. Fix this by passing oplock from the callers to
cifs_new_fileinfo().

This change dates back to commit a6ce4932 (2.6.30-rc3). So, all the affected
versions will need this fix. Please Cc stable once reviewed and accepted.

Reviewed-by: Jeff Layton <[email protected]>
Signed-off-by: Suresh Jayaraman <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/cifsproto.h | 3 ++-
fs/cifs/dir.c | 12 +++++-------
fs/cifs/file.c | 4 ++--
3 files changed, 9 insertions(+), 10 deletions(-)

--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -107,7 +107,8 @@ extern struct timespec cnvrtDosUnixTm(__

extern struct cifsFileInfo *cifs_new_fileinfo(struct inode *newinode,
__u16 fileHandle, struct file *file,
- struct vfsmount *mnt, unsigned int oflags);
+ struct vfsmount *mnt, unsigned int oflags,
+ __u32 oplock);
extern int cifs_posix_open(char *full_path, struct inode **pinode,
struct super_block *sb,
int mode, int oflags,
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -132,9 +132,9 @@ cifs_bp_rename_retry:

struct cifsFileInfo *
cifs_new_fileinfo(struct inode *newinode, __u16 fileHandle,
- struct file *file, struct vfsmount *mnt, unsigned int oflags)
+ struct file *file, struct vfsmount *mnt, unsigned int oflags,
+ __u32 oplock)
{
- int oplock = 0;
struct cifsFileInfo *pCifsFile;
struct cifsInodeInfo *pCifsInode;
struct cifs_sb_info *cifs_sb = CIFS_SB(mnt->mnt_sb);
@@ -143,9 +143,6 @@ cifs_new_fileinfo(struct inode *newinode
if (pCifsFile == NULL)
return pCifsFile;

- if (oplockEnabled)
- oplock = REQ_OPLOCK;
-
pCifsFile->netfid = fileHandle;
pCifsFile->pid = current->tgid;
pCifsFile->pInode = igrab(newinode);
@@ -468,7 +465,7 @@ cifs_create_set_dentry:
}

pfile_info = cifs_new_fileinfo(newinode, fileHandle, filp,
- nd->path.mnt, oflags);
+ nd->path.mnt, oflags, oplock);
if (pfile_info == NULL) {
fput(filp);
CIFSSMBClose(xid, tcon, fileHandle);
@@ -729,7 +726,8 @@ cifs_lookup(struct inode *parent_dir_ino

cfile = cifs_new_fileinfo(newInode, fileHandle, filp,
nd->path.mnt,
- nd->intent.open.flags);
+ nd->intent.open.flags,
+ oplock);
if (cfile == NULL) {
fput(filp);
CIFSSMBClose(xid, pTcon, fileHandle);
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -277,7 +277,7 @@ int cifs_open(struct inode *inode, struc

pCifsFile = cifs_new_fileinfo(inode, netfid, file,
file->f_path.mnt,
- oflags);
+ oflags, oplock);
if (pCifsFile == NULL) {
CIFSSMBClose(xid, tcon, netfid);
rc = -ENOMEM;
@@ -370,7 +370,7 @@ int cifs_open(struct inode *inode, struc
goto out;

pCifsFile = cifs_new_fileinfo(inode, netfid, file, file->f_path.mnt,
- file->f_flags);
+ file->f_flags, oplock);
if (pCifsFile == NULL) {
rc = -ENOMEM;
goto out;

2010-11-19 22:15:14

by Greg KH

[permalink] [raw]
Subject: [25/66] KVM: X86: Report SVM bit to userspace only when supported

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Joerg Roedel <[email protected]>

commit 4c62a2dc92518c5adf434df8e5c2283c6762672a upstream.

This patch fixes a bug in KVM where it _always_ reports the
support of the SVM feature to userspace. But KVM only
supports SVM on AMD hardware and only when it is enabled in
the kernel module. This patch fixes the wrong reporting.

Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Avi Kivity <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/svm.c | 4 ++++
arch/x86/kvm/x86.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3354,6 +3354,10 @@ static void svm_cpuid_update(struct kvm_
static void svm_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry)
{
switch (func) {
+ case 0x80000001:
+ if (nested)
+ entry->ecx |= (1 << 2); /* Set SVM bit */
+ break;
case 0x8000000A:
entry->eax = 1; /* SVM revision 1 */
entry->ebx = 8; /* Lets support 8 ASIDs in case we add proper
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1994,7 +1994,7 @@ static void do_cpuid_ent(struct kvm_cpui
0 /* Reserved, AES */ | F(XSAVE) | 0 /* OSXSAVE */ | F(AVX);
/* cpuid 0x80000001.ecx */
const u32 kvm_supported_word6_x86_features =
- F(LAHF_LM) | F(CMP_LEGACY) | F(SVM) | 0 /* ExtApicSpace */ |
+ F(LAHF_LM) | F(CMP_LEGACY) | 0 /*SVM*/ | 0 /* ExtApicSpace */ |
F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(XOP) |
0 /* SKINIT */ | 0 /* WDT */;

2010-11-19 22:13:48

by Greg KH

[permalink] [raw]
Subject: [31/66] drivers/net/wireless/p54/eeprom.c: Return -ENOMEM on memory allocation failure

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Julia Lawall <[email protected]>

commit 0d91f22b75347d9503b17a42b6c74d3f7750acd6 upstream.

In this code, 0 is returned on memory allocation failure, even though other
failures return -ENOMEM or other similar values.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression ret;
expression x,e1,e2,e3;
@@

ret = 0
... when != ret = e1
*x = \(kmalloc\|kcalloc\|kzalloc\)(...)
... when != ret = e2
if (x == NULL) { ... when != ret = e3
return ret;
}
// </smpl>

Signed-off-by: Julia Lawall <[email protected]>
Acked-by: Christian Lamparter <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/p54/eeprom.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -260,8 +260,10 @@ static int p54_generate_channel_lists(st
list->max_entries = max_channel_num;
list->channels = kzalloc(sizeof(struct p54_channel_entry) *
max_channel_num, GFP_KERNEL);
- if (!list->channels)
+ if (!list->channels) {
+ ret = -ENOMEM;
goto free;
+ }

for (i = 0; i < max_channel_num; i++) {
if (i < priv->iq_autocal_len) {

2010-11-19 22:15:54

by Greg KH

[permalink] [raw]
Subject: [24/66] x86, vm86: Fix preemption bug for int1 debug and int3 breakpoint handlers.

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Bart Oldeman <[email protected]>

commit 6554287b1de0448f1e02e200d02b43914e997d15 upstream.

Impact: fix kernel bug such as:
BUG: scheduling while atomic: dosemu.bin/19680/0x00000004
See also Ubuntu bug 455067 at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/455067

Commits 4915a35e35a037254550a2ba9f367a812bc37d40
("Use preempt_conditional_sti/cli in do_int3, like on x86_64.")
and 3d2a71a596bd9c761c8487a2178e95f8a61da083
("x86, traps: converge do_debug handlers")
started disabling preemption in int1 and int3 handlers on i386.
The problem with vm86 is that the call to handle_vm86_trap() may jump
straight to entry_32.S and never returns so preempt is never enabled
again, and there is an imbalance in the preempt count.

Commit be716615fe596ee117292dc615e95f707fb67fd1 ("x86, vm86:
fix preemption bug"), which was later (accidentally?) reverted by commit
08d68323d1f0c34452e614263b212ca556dae47f ("hw-breakpoints: modifying
generic debug exception to use thread-specific debug registers")
fixed the problem for debug exceptions but not for breakpoints.

There are three solutions to this problem.

1. Reenable preemption before calling handle_vm86_trap(). This
was the approach that was later reverted.

2. Do not disable preemption for i386 in breakpoint and debug handlers.
This was the situation before October 2008. As far as I understand
preemption only needs to be disabled on x86_64 because a seperate stack is
used, but it's nice to have things work the same way on
i386 and x86_64.

3. Let handle_vm86_trap() return instead of jumping to assembly code.
By setting a flag in _TIF_WORK_MASK, either TIF_IRET or TIF_NOTIFY_RESUME,
the code in entry_32.S is instructed to return to 32 bit mode from
V86 mode. The logic in entry_32.S was already present to handle signals.
(I chose TIF_IRET because it's slightly more efficient in
do_notify_resume() in signal.c, but in fact TIF_IRET can probably be
replaced by TIF_NOTIFY_RESUME everywhere.)

I'm submitting approach 3, because I believe it is the most elegant
and prevents future confusion. Still, an obvious
preempt_conditional_cli(regs); is necessary in traps.c to correct the
bug.

[ hpa: This is technically a regression, but because:
1. the regression is so old,
2. the patch seems relatively high risk, justifying more testing, and
3. we're late in the 2.6.36-rc cycle,

I'm queuing it up for the 2.6.37 merge window. It might, however,
justify as a -stable backport at a latter time, hence Cc: stable. ]

Signed-off-by: Bart Oldeman <[email protected]>
LKML-Reference: <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: K.Prasad <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Alexander van Heukelum <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/traps.c | 1 +
arch/x86/kernel/vm86_32.c | 10 ++++++++--
2 files changed, 9 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -575,6 +575,7 @@ dotraplinkage void __kprobes do_debug(st
if (regs->flags & X86_VM_MASK) {
handle_vm86_trap((struct kernel_vm86_regs *) regs,
error_code, 1);
+ preempt_conditional_cli(regs);
return;
}

--- a/arch/x86/kernel/vm86_32.c
+++ b/arch/x86/kernel/vm86_32.c
@@ -551,8 +551,14 @@ cannot_handle:
int handle_vm86_trap(struct kernel_vm86_regs *regs, long error_code, int trapno)
{
if (VMPI.is_vm86pus) {
- if ((trapno == 3) || (trapno == 1))
- return_to_32bit(regs, VM86_TRAP + (trapno << 8));
+ if ((trapno == 3) || (trapno == 1)) {
+ KVM86->regs32->ax = VM86_TRAP + (trapno << 8);
+ /* setting this flag forces the code in entry_32.S to
+ call save_v86_state() and change the stack pointer
+ to KVM86->regs32 */
+ set_thread_flag(TIF_IRET);
+ return 0;
+ }
do_int(regs, trapno, (unsigned char __user *) (regs->pt.ss << 4), SP(regs));
return 0;
}

2010-11-19 22:16:36

by Greg KH

[permalink] [raw]
Subject: [19/66] x86, kexec: Make sure to stop all CPUs before exiting the kernel

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alok Kataria <[email protected]>

commit 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce upstream.

x86 smp_ops now has a new op, stop_other_cpus which takes a parameter
"wait" this allows the caller to specify if it wants to stop until all
the cpus have processed the stop IPI. This is required specifically
for the kexec case where we should wait for all the cpus to be stopped
before starting the new kernel. We now wait for the cpus to stop in
all cases except for panic/kdump where we expect things to be broken
and we are doing our best to make things work anyway.

This patch fixes a legitimate regression, which was introduced during
2.6.30, by commit id 4ef702c10b5df18ab04921fc252c26421d4d6c75.

Signed-off-by: Alok N Kataria <[email protected]>
LKML-Reference: <[email protected]>
Cc: Eric W. Biederman <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/asm/smp.h | 9 +++++++--
arch/x86/kernel/reboot.c | 2 +-
arch/x86/kernel/smp.c | 15 +++++++++------
arch/x86/xen/enlighten.c | 2 +-
arch/x86/xen/smp.c | 6 +++---
5 files changed, 21 insertions(+), 13 deletions(-)

--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -50,7 +50,7 @@ struct smp_ops {
void (*smp_prepare_cpus)(unsigned max_cpus);
void (*smp_cpus_done)(unsigned max_cpus);

- void (*smp_send_stop)(void);
+ void (*stop_other_cpus)(int wait);
void (*smp_send_reschedule)(int cpu);

int (*cpu_up)(unsigned cpu);
@@ -73,7 +73,12 @@ extern struct smp_ops smp_ops;

static inline void smp_send_stop(void)
{
- smp_ops.smp_send_stop();
+ smp_ops.stop_other_cpus(0);
+}
+
+static inline void stop_other_cpus(void)
+{
+ smp_ops.stop_other_cpus(1);
}

static inline void smp_prepare_boot_cpu(void)
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -641,7 +641,7 @@ void native_machine_shutdown(void)
/* O.K Now that I'm on the appropriate processor,
* stop all of the others.
*/
- smp_send_stop();
+ stop_other_cpus();
#endif

lapic_shutdown();
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -159,10 +159,10 @@ asmlinkage void smp_reboot_interrupt(voi
irq_exit();
}

-static void native_smp_send_stop(void)
+static void native_stop_other_cpus(int wait)
{
unsigned long flags;
- unsigned long wait;
+ unsigned long timeout;

if (reboot_force)
return;
@@ -179,9 +179,12 @@ static void native_smp_send_stop(void)
if (num_online_cpus() > 1) {
apic->send_IPI_allbutself(REBOOT_VECTOR);

- /* Don't wait longer than a second */
- wait = USEC_PER_SEC;
- while (num_online_cpus() > 1 && wait--)
+ /*
+ * Don't wait longer than a second if the caller
+ * didn't ask us to wait.
+ */
+ timeout = USEC_PER_SEC;
+ while (num_online_cpus() > 1 && (wait || timeout--))
udelay(1);
}

@@ -227,7 +230,7 @@ struct smp_ops smp_ops = {
.smp_prepare_cpus = native_smp_prepare_cpus,
.smp_cpus_done = native_smp_cpus_done,

- .smp_send_stop = native_smp_send_stop,
+ .stop_other_cpus = native_stop_other_cpus,
.smp_send_reschedule = native_smp_send_reschedule,

.cpu_up = native_cpu_up,
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1018,7 +1018,7 @@ static void xen_reboot(int reason)
struct sched_shutdown r = { .reason = reason };

#ifdef CONFIG_SMP
- smp_send_stop();
+ stop_other_cpus();
#endif

if (HYPERVISOR_sched_op(SCHEDOP_shutdown, &r))
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -400,9 +400,9 @@ static void stop_self(void *v)
BUG();
}

-static void xen_smp_send_stop(void)
+static void xen_stop_other_cpus(int wait)
{
- smp_call_function(stop_self, NULL, 0);
+ smp_call_function(stop_self, NULL, wait);
}

static void xen_smp_send_reschedule(int cpu)
@@ -470,7 +470,7 @@ static const struct smp_ops xen_smp_ops
.cpu_disable = xen_cpu_disable,
.play_dead = xen_play_dead,

- .smp_send_stop = xen_smp_send_stop,
+ .stop_other_cpus = xen_stop_other_cpus,
.smp_send_reschedule = xen_smp_send_reschedule,

.send_call_func_ipi = xen_smp_send_call_function_ipi,

2010-11-19 22:16:07

by Greg KH

[permalink] [raw]
Subject: [23/66] x86, kdump: Change copy_oldmem_page() to use cached addressing

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Cliff Wickman <[email protected]>

commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream.

The copy of /proc/vmcore to a user buffer proceeds much faster
if the kernel addresses memory as cached.

With this patch we have seen an increase in transfer rate from
less than 15MB/s to 80-460MB/s, depending on size of the
transfer. This makes a big difference in time needed to save a
system dump.

Signed-off-by: Cliff Wickman <[email protected]>
Acked-by: "Eric W. Biederman" <[email protected]>
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/crash_dump_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -34,7 +34,7 @@ ssize_t copy_oldmem_page(unsigned long p
if (!csize)
return 0;

- vaddr = ioremap(pfn << PAGE_SHIFT, PAGE_SIZE);
+ vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
if (!vaddr)
return -ENOMEM;


2010-11-19 22:16:32

by Greg KH

[permalink] [raw]
Subject: [21/66] x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Andreas Herrmann <[email protected]>

commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d upstream.

Instead of adapting the CPU family check in amd_special_default_mtrr()
for each new CPU family assume that all new AMD CPUs support the
necessary bits in SYS_CFG MSR.

Tom2Enabled is architectural (defined in APM Vol.2).
Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
In pre K8-NPT BKDG this bit is reserved (read as zero).

W/o this adaption Linux would unnecessarily complain about bad MTRR
settings on every new AMD CPU family, e.g.

[ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.

Signed-off-by: Andreas Herrmann <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void

if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
return 0;
- if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
+ if (boot_cpu_data.x86 < 0xf)
return 0;
/* In case some hypervisor doesn't pass SYSCFG through: */
if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)

2010-11-19 22:17:08

by Greg KH

[permalink] [raw]
Subject: [17/66] x86, cpu: Fix renamed, not-yet-shipping AMD CPUID feature bit

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Andre Przywara <[email protected]>

commit 7ef8aa72ab176e0288f363d1247079732c5d5792 upstream.

The AMD SSE5 feature set as-it has been replaced by some extensions
to the AVX instruction set. Thus the bit formerly advertised as SSE5
is re-used for one of these extensions (XOP).
Although this changes the /proc/cpuinfo output, it is not user visible, as
there are no CPUs (yet) having this feature.
To avoid confusion this should be added to the stable series, too.

Signed-off-by: Andre Przywara <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/asm/cpufeature.h | 2 +-
arch/x86/kvm/x86.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -152,7 +152,7 @@
#define X86_FEATURE_3DNOWPREFETCH (6*32+ 8) /* 3DNow prefetch instructions */
#define X86_FEATURE_OSVW (6*32+ 9) /* OS Visible Workaround */
#define X86_FEATURE_IBS (6*32+10) /* Instruction Based Sampling */
-#define X86_FEATURE_SSE5 (6*32+11) /* SSE-5 */
+#define X86_FEATURE_XOP (6*32+11) /* extended AVX instructions */
#define X86_FEATURE_SKINIT (6*32+12) /* SKINIT/STGI instructions */
#define X86_FEATURE_WDT (6*32+13) /* Watchdog timer */
#define X86_FEATURE_NODEID_MSR (6*32+19) /* NodeId MSR */
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1996,7 +1996,7 @@ static void do_cpuid_ent(struct kvm_cpui
const u32 kvm_supported_word6_x86_features =
F(LAHF_LM) | F(CMP_LEGACY) | F(SVM) | 0 /* ExtApicSpace */ |
F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
- F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(SSE5) |
+ F(3DNOWPREFETCH) | 0 /* OSVW */ | 0 /* IBS */ | F(XOP) |
0 /* SKINIT */ | 0 /* WDT */;

/* all calls to cpuid_count() should be made on the same cpu */

2010-11-19 22:17:26

by Greg KH

[permalink] [raw]
Subject: [16/66] mm, x86: Saving vmcore with non-lazy freeing of vmas

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Cliff Wickman <[email protected]>

commit 3ee48b6af49cf534ca2f481ecc484b156a41451d upstream.

During the reading of /proc/vmcore the kernel is doing
ioremap()/iounmap() repeatedly. And the buildup of un-flushed
vm_area_struct's is causing a great deal of overhead. (rb_next()
is chewing up most of that time).

This solution is to provide function set_iounmap_nonlazy(). It
causes a subsequent call to iounmap() to immediately purge the
vma area (with try_purge_vmap_area_lazy()).

With this patch we have seen the time for writing a 250MB
compressed dump drop from 71 seconds to 44 seconds.

Signed-off-by: Cliff Wickman <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/include/asm/io.h | 1 +
arch/x86/kernel/crash_dump_64.c | 1 +
mm/vmalloc.c | 9 +++++++++
3 files changed, 11 insertions(+)

--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -206,6 +206,7 @@ static inline void __iomem *ioremap(reso

extern void iounmap(volatile void __iomem *addr);

+extern void set_iounmap_nonlazy(void);

#ifdef __KERNEL__

--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -46,6 +46,7 @@ ssize_t copy_oldmem_page(unsigned long p
} else
memcpy(buf, vaddr + offset, csize);

+ set_iounmap_nonlazy();
iounmap(vaddr);
return csize;
}
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -517,6 +517,15 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
static void purge_fragmented_blocks_allcpus(void);

/*
+ * called before a call to iounmap() if the caller wants vm_area_struct's
+ * immediately freed.
+ */
+void set_iounmap_nonlazy(void)
+{
+ atomic_set(&vmap_lazy_nr, lazy_max_pages()+1);
+}
+
+/*
* Purges all lazily-freed vmap areas.
*
* If sync is 0 then don't purge if there is already a purge in progress.

2010-11-19 22:16:34

by Greg KH

[permalink] [raw]
Subject: [20/66] x86, olpc: Dont retry EC commands forever

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Paul Fox <[email protected]>

commit 286e5b97eb22baab9d9a41ca76c6b933a484252c upstream.

Avoids a potential infinite loop.

It was observed once, during an EC hacking/debugging
session - not in regular operation.

Signed-off-by: Daniel Drake <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/olpc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/olpc.c
+++ b/arch/x86/kernel/olpc.c
@@ -114,6 +114,7 @@ int olpc_ec_cmd(unsigned char cmd, unsig
unsigned long flags;
int ret = -EIO;
int i;
+ int restarts = 0;

spin_lock_irqsave(&ec_lock, flags);

@@ -169,7 +170,9 @@ restart:
if (wait_on_obf(0x6c, 1)) {
printk(KERN_ERR "olpc-ec: timeout waiting for"
" EC to provide data!\n");
- goto restart;
+ if (restarts++ < 10)
+ goto restart;
+ goto err;
}
outbuf[i] = inb(0x68);
pr_devel("olpc-ec: received 0x%x\n", outbuf[i]);

2010-11-19 22:04:09

by Greg KH

[permalink] [raw]
Subject: [04/66] perf_events: Fix bogus AMD64 generic TLB events

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Stephane Eranian <[email protected]>

commit ba0cef3d149ce4db293c572bf36ed352b11ce7b9 upstream.

PERF_COUNT_HW_CACHE_DTLB:READ:MISS had a bogus umask value of 0 which
counts nothing. Needed to be 0x7 (to count all possibilities).

PERF_COUNT_HW_CACHE_ITLB:READ:MISS had a bogus umask value of 0 which
counts nothing. Needed to be 0x3 (to count all possibilities).

Signed-off-by: Stephane Eranian <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Robert Richter <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/cpu/perf_event_amd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event_amd.c
+++ b/arch/x86/kernel/cpu/perf_event_amd.c
@@ -52,7 +52,7 @@ static __initconst const u64 amd_hw_cach
[ C(DTLB) ] = {
[ C(OP_READ) ] = {
[ C(RESULT_ACCESS) ] = 0x0040, /* Data Cache Accesses */
- [ C(RESULT_MISS) ] = 0x0046, /* L1 DTLB and L2 DLTB Miss */
+ [ C(RESULT_MISS) ] = 0x0746, /* L1_DTLB_AND_L2_DLTB_MISS.ALL */
},
[ C(OP_WRITE) ] = {
[ C(RESULT_ACCESS) ] = 0,
@@ -66,7 +66,7 @@ static __initconst const u64 amd_hw_cach
[ C(ITLB) ] = {
[ C(OP_READ) ] = {
[ C(RESULT_ACCESS) ] = 0x0080, /* Instruction fecthes */
- [ C(RESULT_MISS) ] = 0x0085, /* Instr. fetch ITLB misses */
+ [ C(RESULT_MISS) ] = 0x0385, /* L1_ITLB_AND_L2_ITLB_MISS.ALL */
},
[ C(OP_WRITE) ] = {
[ C(RESULT_ACCESS) ] = -1,

2010-11-19 22:17:41

by Greg KH

[permalink] [raw]
Subject: [15/66] intel_idle: do not use the LAPIC timer for ATOM C2

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Len Brown <[email protected]>

commit c25d29952b2a8c9aaf00e081c9162a0e383030cd upstream.

If we use the LAPIC timer during ATOM C2 on
some nvidia chisets, the system stalls.

https://bugzilla.kernel.org/show_bug.cgi?id=21032

Signed-off-by: Len Brown <[email protected]>
Cc: Tom Gundersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/idle/intel_idle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -276,7 +276,7 @@ static int intel_idle_probe(void)

case 0x1C: /* 28 - Atom Processor */
case 0x26: /* 38 - Lincroft Atom Processor */
- lapic_timer_reliable_states = (1 << 2) | (1 << 1); /* C2, C1 */
+ lapic_timer_reliable_states = (1 << 1); /* C1 */
cpuidle_state_table = atom_cstates;
break;
#ifdef FUTURE_USE

2010-11-19 22:17:55

by Greg KH

[permalink] [raw]
Subject: [14/66] libahci: fix result_tf handling after an ATA PIO data-in command

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Tejun Heo <[email protected]>

commit 6ad601955315b010a117306b994f2204fae85fdc upstream.

ATA devices don't send D2H Reg FIS after an successful ATA PIO data-in
command. The host is supposed to take the TF and E_Status of the
preceding PIO Setup FIS. Update ahci_qc_fill_rtf() such that it takes
TF + E_Status from PIO Setup FIS after a successful ATA PIO data-in
command.

Without this patch, result_tf for such a command is filled with the
content of the previous D2H Reg FIS which belongs to a previous
command, which can make the command incorrectly seen as failed.

* Patch updated to grab the whole TF + E_Status from PIO Setup FIS
instead of just E_Status as suggested by Robert Hancock.

Signed-off-by: Tejun Heo <[email protected]>
Reported-by: Mark Lord <[email protected]>
Cc: Robert Hancock <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/ahci.h | 1 +
drivers/ata/libahci.c | 18 +++++++++++++++---
2 files changed, 16 insertions(+), 3 deletions(-)

--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -72,6 +72,7 @@ enum {
AHCI_CMD_RESET = (1 << 8),
AHCI_CMD_CLR_BUSY = (1 << 10),

+ RX_FIS_PIO_SETUP = 0x20, /* offset of PIO Setup FIS data */
RX_FIS_D2H_REG = 0x40, /* offset of D2H Register FIS data */
RX_FIS_SDB = 0x58, /* offset of SDB FIS data */
RX_FIS_UNK = 0x60, /* offset of Unknown FIS data */
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1830,12 +1830,24 @@ static unsigned int ahci_qc_issue(struct
static bool ahci_qc_fill_rtf(struct ata_queued_cmd *qc)
{
struct ahci_port_priv *pp = qc->ap->private_data;
- u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
+ u8 *rx_fis = pp->rx_fis;

if (pp->fbs_enabled)
- d2h_fis += qc->dev->link->pmp * AHCI_RX_FIS_SZ;
+ rx_fis += qc->dev->link->pmp * AHCI_RX_FIS_SZ;
+
+ /*
+ * After a successful execution of an ATA PIO data-in command,
+ * the device doesn't send D2H Reg FIS to update the TF and
+ * the host should take TF and E_Status from the preceding PIO
+ * Setup FIS.
+ */
+ if (qc->tf.protocol == ATA_PROT_PIO && qc->dma_dir == DMA_FROM_DEVICE &&
+ !(qc->flags & ATA_QCFLAG_FAILED)) {
+ ata_tf_from_fis(rx_fis + RX_FIS_PIO_SETUP, &qc->result_tf);
+ qc->result_tf.command = (rx_fis + RX_FIS_PIO_SETUP)[15];
+ } else
+ ata_tf_from_fis(rx_fis + RX_FIS_D2H_REG, &qc->result_tf);

- ata_tf_from_fis(d2h_fis, &qc->result_tf);
return true;
}


2010-11-19 22:04:06

by Greg KH

[permalink] [raw]
Subject: [03/66] Staging: phison: fix problem caused by libata change

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Greg Kroah-Hartman <[email protected]>

commit cf10700bf8047f0668dd874b607f89516612e6c7 upstream.

The libata core changed this function so it needed to call a different
one.

See https://bugzilla.kernel.org/show_bug.cgi?id=19872 for details.

Reported-by: Heinz Wiesinger <[email protected]>
Tested-by: Heinz Wiesinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/phison/phison.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/phison/phison.c
+++ b/drivers/staging/phison/phison.c
@@ -62,7 +62,7 @@ static int phison_init_one(struct pci_de
};
const struct ata_port_info *ppi[] = { &info, NULL };

- ret = ata_pci_sff_init_one(pdev, ppi, &phison_sht, NULL, 0);
+ ret = ata_pci_bmdma_init_one(pdev, ppi, &phison_sht, NULL, 0);

dev_dbg(&pdev->dev, "phison_init_one(), ret = %x\n", ret);


2010-11-19 22:18:10

by Greg KH

[permalink] [raw]
Subject: [12/66] futex: Fix errors in nested key ref-counting

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Darren Hart <[email protected]>

commit 7ada876a8703f23befbb20a7465a702ee39b1704 upstream.

futex_wait() is leaking key references due to futex_wait_setup()
acquiring an additional reference via the queue_lock() routine. The
nested key ref-counting has been masking bugs and complicating code
analysis. queue_lock() is only called with a previously ref-counted
key, so remove the additional ref-counting from the queue_(un)lock()
functions.

Also futex_wait_requeue_pi() drops one key reference too many in
unqueue_me_pi(). Remove the key reference handling from
unqueue_me_pi(). This was paired with a queue_lock() in
futex_lock_pi(), so the count remains unchanged.

Document remaining nested key ref-counting sites.

Signed-off-by: Darren Hart <[email protected]>
Reported-and-tested-by: Matthieu Fertré<[email protected]>
Reported-by: Louis Rilling<[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: John Kacur <[email protected]>
Cc: Rusty Russell <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/futex.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1363,7 +1363,6 @@ static inline struct futex_hash_bucket *
{
struct futex_hash_bucket *hb;

- get_futex_key_refs(&q->key);
hb = hash_futex(&q->key);
q->lock_ptr = &hb->lock;

@@ -1375,7 +1374,6 @@ static inline void
queue_unlock(struct futex_q *q, struct futex_hash_bucket *hb)
{
spin_unlock(&hb->lock);
- drop_futex_key_refs(&q->key);
}

/**
@@ -1480,8 +1478,6 @@ static void unqueue_me_pi(struct futex_q
q->pi_state = NULL;

spin_unlock(q->lock_ptr);
-
- drop_futex_key_refs(&q->key);
}

/*
@@ -1812,7 +1808,10 @@ static int futex_wait(u32 __user *uaddr,
}

retry:
- /* Prepare to wait on uaddr. */
+ /*
+ * Prepare to wait on uaddr. On success, holds hb lock and increments
+ * q.key refs.
+ */
ret = futex_wait_setup(uaddr, val, fshared, &q, &hb);
if (ret)
goto out;
@@ -1822,24 +1821,23 @@ retry:

/* If we were woken (and unqueued), we succeeded, whatever. */
ret = 0;
+ /* unqueue_me() drops q.key ref */
if (!unqueue_me(&q))
- goto out_put_key;
+ goto out;
ret = -ETIMEDOUT;
if (to && !to->task)
- goto out_put_key;
+ goto out;

/*
* We expect signal_pending(current), but we might be the
* victim of a spurious wakeup as well.
*/
- if (!signal_pending(current)) {
- put_futex_key(fshared, &q.key);
+ if (!signal_pending(current))
goto retry;
- }

ret = -ERESTARTSYS;
if (!abs_time)
- goto out_put_key;
+ goto out;

restart = &current_thread_info()->restart_block;
restart->fn = futex_wait_restart;
@@ -1856,8 +1854,6 @@ retry:

ret = -ERESTART_RESTARTBLOCK;

-out_put_key:
- put_futex_key(fshared, &q.key);
out:
if (to) {
hrtimer_cancel(&to->timer);
@@ -2236,7 +2232,10 @@ static int futex_wait_requeue_pi(u32 __u
q.rt_waiter = &rt_waiter;
q.requeue_pi_key = &key2;

- /* Prepare to wait on uaddr. */
+ /*
+ * Prepare to wait on uaddr. On success, increments q.key (key1) ref
+ * count.
+ */
ret = futex_wait_setup(uaddr, val, fshared, &q, &hb);
if (ret)
goto out_key2;
@@ -2254,7 +2253,9 @@ static int futex_wait_requeue_pi(u32 __u
* In order for us to be here, we know our q.key == key2, and since
* we took the hb->lock above, we also know that futex_requeue() has
* completed and we no longer have to concern ourselves with a wakeup
- * race with the atomic proxy lock acquition by the requeue code.
+ * race with the atomic proxy lock acquisition by the requeue code. The
+ * futex_requeue dropped our key1 reference and incremented our key2
+ * reference count.
*/

/* Check if the requeue code acquired the second futex for us. */

2010-11-19 22:18:27

by Greg KH

[permalink] [raw]
Subject: [11/66] Bluetooth: fix oops in l2cap_connect_req

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Nathan Holstein <[email protected]>

commit d793fe8caa3911e6a1e826b45d4ee00d250cdec8 upstream.

In error cases when the ACL is insecure or we fail to allocate a new
struct sock, we jump to the "response" label. If so, "sk" will be
null and the kernel crashes.

Signed-off-by: Nathan Holstein <[email protected]>
Acked-by: Marcel Holtmann <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/bluetooth/l2cap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2891,7 +2891,7 @@ static inline int l2cap_connect_req(stru
struct l2cap_chan_list *list = &conn->chan_list;
struct l2cap_conn_req *req = (struct l2cap_conn_req *) data;
struct l2cap_conn_rsp rsp;
- struct sock *parent, *uninitialized_var(sk);
+ struct sock *parent, *sk = NULL;
int result, status = L2CAP_CS_NO_INFO;

u16 dcid = 0, scid = __le16_to_cpu(req->scid);
@@ -3000,7 +3000,7 @@ sendresp:
L2CAP_INFO_REQ, sizeof(info), &info);
}

- if (!(l2cap_pi(sk)->conf_state & L2CAP_CONF_REQ_SENT) &&
+ if (sk && !(l2cap_pi(sk)->conf_state & L2CAP_CONF_REQ_SENT) &&
result == L2CAP_CR_SUCCESS) {
u8 buf[128];
l2cap_pi(sk)->conf_state |= L2CAP_CONF_REQ_SENT;

2010-11-19 22:18:41

by Greg KH

[permalink] [raw]
Subject: [10/66] bluetooth: Fix missing NULL check

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Alan Cox <[email protected]>

commit c19483cc5e56ac5e22dd19cf25ba210ab1537773 upstream.

Fortunately this is only exploitable on very unusual hardware.

[Reported a while ago but nothing happened so just fixing it]

Signed-off-by: Alan Cox <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/bluetooth/hci_ldisc.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -256,9 +256,16 @@ static int hci_uart_tty_open(struct tty_

BT_DBG("tty %p", tty);

+ /* FIXME: This btw is bogus, nothing requires the old ldisc to clear
+ the pointer */
if (hu)
return -EEXIST;

+ /* Error if the tty has no write op instead of leaving an exploitable
+ hole */
+ if (tty->ops->write == NULL)
+ return -EOPNOTSUPP;
+
if (!(hu = kzalloc(sizeof(struct hci_uart), GFP_KERNEL))) {
BT_ERR("Can't allocate control structure");
return -ENFILE;

2010-11-19 22:18:55

by Greg KH

[permalink] [raw]
Subject: [08/66] sched: Drop all load weight manipulation for RT tasks

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Linus Walleij <[email protected]>

commit 17bdcf949d03306b308c5fb694849cd35f119807 upstream.

Load weights are for the CFS, they do not belong in the RT task. This makes all
RT scheduling classes leave the CFS weights alone.

This fixes a real bug as well: I noticed the following phonomena: a process
elevated to SCHED_RR forks with SCHED_RESET_ON_FORK set, and the child is
indeed SCHED_OTHER, and the niceval is indeed reset to 0. However the weight
inserted by set_load_weight() remains at 0, giving the task insignificat
priority.

With this fix, the weight is reset to what the task had before being elevated
to SCHED_RR/SCHED_FIFO.

Cc: Lennart Poettering <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/sched.c | 6 ------
1 file changed, 6 deletions(-)

--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1858,12 +1858,6 @@ static void dec_nr_running(struct rq *rq

static void set_load_weight(struct task_struct *p)
{
- if (task_has_rt_policy(p)) {
- p->se.load.weight = 0;
- p->se.load.inv_weight = WMULT_CONST;
- return;
- }
-
/*
* SCHED_IDLE tasks get minimal weight:
*/

2010-11-19 22:04:04

by Greg KH

[permalink] [raw]
Subject: [01/66] staging: usbip: Notify usb core of port status changes

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Max Vozeler <[email protected]>

commit 0c9a32f0192e656daa2ff3c9149f6d71b4a1b873 upstream.

This patch changes vhci to behave like dummy and
other hcds when disconnecting a device.

Previously detaching a device from the root hub
did not notify the usb core of the disconnect and
left the device visible.

Signed-off-by: Max Vozeler <[email protected]>
Reported-by: Marco Lancione <[email protected]>
Tested-by: Luc Jalbert <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/usbip/vhci_hcd.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -164,6 +164,8 @@ void rh_port_disconnect(int rhport)
* spin_unlock(&vdev->ud.lock); */

spin_unlock_irqrestore(&the_controller->lock, flags);
+
+ usb_hcd_poll_rh_status(vhci_to_hcd(the_controller));
}



2010-11-19 22:18:53

by Greg KH

[permalink] [raw]
Subject: [09/66] sched: Fix string comparison in /proc/sched_features

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Mathieu Desnoyers <[email protected]>

commit 7740191cd909b75d75685fb08a5d1f54b8a9d28b upstream.

Fix incorrect handling of the following case:

INTERACTIVE
INTERACTIVE_SOMETHING_ELSE

The comparison only checks up to each element's length.

Changelog since v1:
- Embellish using some Rostedtisms.
[ mingo: ^^ == smaller and cleaner ]

Signed-off-by: Mathieu Desnoyers <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tony Lindgren <[email protected]>
LKML-Reference: <20100913214700.GB16118@Krystal>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/sched.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -723,7 +723,7 @@ sched_feat_write(struct file *filp, cons
size_t cnt, loff_t *ppos)
{
char buf[64];
- char *cmp = buf;
+ char *cmp;
int neg = 0;
int i;

@@ -734,6 +734,7 @@ sched_feat_write(struct file *filp, cons
return -EFAULT;

buf[cnt] = 0;
+ cmp = strstrip(buf);

if (strncmp(buf, "NO_", 3) == 0) {
neg = 1;
@@ -741,9 +742,7 @@ sched_feat_write(struct file *filp, cons
}

for (i = 0; sched_feat_names[i]; i++) {
- int len = strlen(sched_feat_names[i]);
-
- if (strncmp(cmp, sched_feat_names[i], len) == 0) {
+ if (strcmp(cmp, sched_feat_names[i]) == 0) {
if (neg)
sysctl_sched_features &= ~(1UL << i);
else

2010-11-19 22:19:41

by Greg KH

[permalink] [raw]
Subject: [06/66] powerpc/perf: Fix sampling enable for PPC970

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Paul Mackerras <[email protected]>

commit 9f5f9ffe50e90ed73040d2100db8bfc341cee352 upstream.

The logic to distinguish marked instruction events from ordinary events
on PPC970 and derivatives was flawed. The result is that instruction
sampling didn't get enabled in the PMU for some marked instruction
events, so they would never trigger. This fixes it by adding the
appropriate break statements in the switch statement.

Reported-by: David Binderman <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kernel/ppc970-pmu.c | 2 ++
1 file changed, 2 insertions(+)

--- a/arch/powerpc/kernel/ppc970-pmu.c
+++ b/arch/powerpc/kernel/ppc970-pmu.c
@@ -169,9 +169,11 @@ static int p970_marked_instr_event(u64 e
switch (unit) {
case PM_VPU:
mask = 0x4c; /* byte 0 bits 2,3,6 */
+ break;
case PM_LSU0:
/* byte 2 bits 0,2,3,4,6; all of byte 1 */
mask = 0x085dff00;
+ break;
case PM_LSU1L:
mask = 0x50 << 24; /* byte 3 bits 4,6 */
break;

2010-11-19 22:19:27

by Greg KH

[permalink] [raw]
Subject: [07/66] pcmcia: synclink_cs: fix information leak to userland

2.6.36-stable review patch. If anyone has any objections, please let us know.

------------------

From: Vasiliy Kulikov <[email protected]>

commit 5b917a1420d3d1a9c8da49fb0090692dc9aaee86 upstream.

Structure new_line is copied to userland with some padding fields unitialized.
It leads to leaking of stack memory.

Signed-off-by: Vasiliy Kulikov <[email protected]>
Signed-off-by: Dominik Brodowski <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/char/pcmcia/synclink_cs.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -4127,6 +4127,8 @@ static int hdlcdev_ioctl(struct net_devi
if (cmd != SIOCWANDEV)
return hdlc_ioctl(dev, ifr, cmd);

+ memset(&new_line, 0, size);
+
switch(ifr->ifr_settings.type) {
case IF_GET_IFACE: /* return current sync_serial_settings */


2010-11-20 00:25:10

by Greg KH

[permalink] [raw]
Subject: Re: [Stable-review] [00/66] 2.6.36.1-stable review

On Fri, Nov 19, 2010 at 11:18:56PM +0100, Nikola Ciprich wrote:
> Hi Greg,
> I guess it's certainly quite late for it now, but would You be willing
> to accept this one for 2.6.36.1 too?
>
> http://www.spinics.net/lists/netdev/msg146227.html
>
> fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=20462
>
> It's been submitted to stable, but for some reason it was omited...

There's been a lot of patches submitted that didn't make it into .36.1
due to time constraints and the already-large patch queue size.

I have a lot pending that will show up in .36.2. If you don't see it
there, please remind me again.

But note, networking patches get sent to me by the network subsystem
maintainer. Please work with David to get that into the stable tree,
he's the one who needs to send this to me.

thanks,

greg k-h

2010-11-20 05:54:30

by Nikola Ciprich

[permalink] [raw]
Subject: Re: [Stable-review] [00/66] 2.6.36.1-stable review

Hi Greg,
I guess it's certainly quite late for it now, but would You be willing
to accept this one for 2.6.36.1 too?

http://www.spinics.net/lists/netdev/msg146227.html

fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=20462

It's been submitted to stable, but for some reason it was omited...
BR
nik



On Fri, Nov 19, 2010 at 02:03:09PM -0800, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.36.1 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.
>
> Responses should be made by Monday, November 22, 2010, 12:00:00 UTC
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.36.1-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
>
> Makefile | 2 +-
> arch/arm/include/asm/kgdb.h | 5 ++-
> arch/arm/kernel/kgdb.c | 2 +-
> arch/arm/mach-cns3xxx/include/mach/debug-macro.S | 2 +-
> arch/powerpc/kernel/ppc970-pmu.c | 2 +
> arch/x86/include/asm/cpufeature.h | 2 +-
> arch/x86/include/asm/io.h | 1 +
> arch/x86/include/asm/mrst.h | 2 +-
> arch/x86/include/asm/smp.h | 9 ++++-
> arch/x86/kernel/apic/io_apic.c | 2 +
> arch/x86/kernel/cpu/mtrr/cleanup.c | 2 +-
> arch/x86/kernel/cpu/perf_event_amd.c | 4 +-
> arch/x86/kernel/crash_dump_64.c | 3 +-
> arch/x86/kernel/olpc.c | 5 ++-
> arch/x86/kernel/reboot.c | 2 +-
> arch/x86/kernel/smp.c | 15 +++++---
> arch/x86/kernel/traps.c | 1 +
> arch/x86/kernel/vm86_32.c | 10 ++++-
> arch/x86/kvm/svm.c | 37 +++++++++++++++++++-
> arch/x86/kvm/x86.c | 4 +-
> arch/x86/xen/enlighten.c | 2 +-
> arch/x86/xen/smp.c | 6 ++--
> drivers/ata/ahci.h | 1 +
> drivers/ata/libahci.c | 18 ++++++++--
> drivers/bluetooth/hci_ldisc.c | 7 ++++
> drivers/char/pcmcia/synclink_cs.c | 2 +
> drivers/idle/intel_idle.c | 2 +-
> drivers/misc/sgi-xp/xpc_uv.c | 17 +++++++++
> drivers/net/wireless/p54/eeprom.c | 4 ++-
> drivers/net/wireless/p54/p54usb.c | 15 ++++++++-
> drivers/platform/x86/asus-laptop.c | 6 ++--
> drivers/scsi/gdth.c | 8 ++++
> drivers/scsi/libsas/sas_ata.c | 1 +
> drivers/scsi/pmcraid.h | 1 -
> drivers/scsi/qla4xxx/ql4_nx.c | 1 +
> drivers/scsi/scsi_lib.c | 3 +-
> drivers/scsi/scsi_sysfs.c | 3 +-
> drivers/scsi/sd.c | 15 +++++---
> drivers/staging/phison/phison.c | 2 +-
> drivers/staging/usbip/usbip_event.c | 16 ++-------
> drivers/staging/usbip/vhci_hcd.c | 2 +
> drivers/usb/core/hcd-pci.c | 4 ++-
> drivers/usb/core/hub.c | 9 +++--
> drivers/usb/core/message.c | 14 ++++----
> drivers/usb/gadget/atmel_usba_udc.c | 3 ++
> drivers/usb/gadget/composite.c | 3 +-
> drivers/usb/gadget/f_acm.c | 2 +-
> drivers/usb/gadget/g_ffs.c | 4 +-
> drivers/usb/gadget/multi.c | 4 +-
> drivers/usb/host/ohci-hcd.c | 9 ++++-
> drivers/usb/host/ohci-pci.c | 18 ++++++++++
> drivers/usb/host/ohci.h | 1 +
> drivers/usb/host/pci-quirks.c | 18 ++++++----
> drivers/usb/host/r8a66597.h | 2 +-
> drivers/usb/musb/blackfin.c | 7 +++-
> drivers/usb/musb/davinci.c | 2 +
> drivers/usb/musb/musb_core.c | 4 --
> drivers/usb/musb/omap2430.c | 1 +
> drivers/usb/musb/tusb6010.c | 4 ++
> drivers/usb/serial/cp210x.c | 2 +
> drivers/usb/serial/ftdi_sio.c | 39 +++++++++++++++++++---
> drivers/usb/serial/ftdi_sio_ids.h | 39 +++++++++++++++++++++-
> drivers/usb/serial/mct_u232.c | 7 +++-
> drivers/usb/serial/opticon.c | 6 ++--
> drivers/usb/serial/option.c | 23 +++++++++++--
> drivers/usb/serial/visor.c | 11 +++++-
> fs/cifs/cifsproto.h | 3 +-
> fs/cifs/dir.c | 12 +++----
> fs/cifs/file.c | 4 +-
> fs/nfs/direct.c | 2 +-
> fs/pipe.c | 2 +-
> kernel/futex.c | 31 +++++++++--------
> kernel/perf_event.c | 8 ++++-
> kernel/sched.c | 13 ++-----
> mm/vmalloc.c | 9 +++++
> net/bluetooth/l2cap.c | 4 +-
> net/netfilter/xt_SECMARK.c | 2 +-
> 77 files changed, 420 insertions(+), 150 deletions(-)
>
> _______________________________________________
> Stable-review mailing list
> [email protected]
> http://linux.kernel.org/mailman/listinfo/stable-review

--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799

http://www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------


Attachments:
(No filename) (6.40 kB)
(No filename) (198.00 B)
Download all attachments

2010-11-20 14:31:36

by Andrew Lutomirski

[permalink] [raw]
Subject: Re: [00/66] 2.6.36.1-stable review

Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.36.1 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.

Can you add ab838338a2a9e0cb8346eb0cab9977be13e8dce5? (Somehow the cc: stable got eaten, but 2.6.36 definitely needs this one. 2.6.35 probably does
as well but I haven't tested it.)

--Andy

>
> Responses should be made by Monday, November 22, 2010, 12:00:00 UTC
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.36.1-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
>

2010-11-20 14:57:27

by Thomas Meyer

[permalink] [raw]
Subject: Re: [00/66] 2.6.36.1-stable review

Am Freitag, den 19.11.2010, 14:03 -0800 schrieb Greg KH:
> This is the start of the stable review cycle for the 2.6.36.1 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.

This one is missing and crashes my 2.6.36 kernel:

https://bugzilla.kernel.org/show_bug.cgi?id=22922

This was fixed in 2.6.37-rc1 in commit: a1c6c5698d53 (ext4: fix
NULL pointer dereference in print_daily_error_info())

kind regards
thomas

2010-11-20 15:53:08

by Greg KH

[permalink] [raw]
Subject: Re: [00/66] 2.6.36.1-stable review

On Sat, Nov 20, 2010 at 04:56:42PM +0100, Thomas Meyer wrote:
> Am Freitag, den 19.11.2010, 14:03 -0800 schrieb Greg KH:
> > This is the start of the stable review cycle for the 2.6.36.1 release.
> > There are 66 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let us know. If anyone is a maintainer of the proper subsystem, and
> > wants to add a Signed-off-by: line to the patch, please respond with it.
>
> This one is missing and crashes my 2.6.36 kernel:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=22922
>
> This was fixed in 2.6.37-rc1 in commit: a1c6c5698d53 (ext4: fix
> NULL pointer dereference in print_daily_error_info())

You need to get the ext4 maintainers to ack that and let me know about
it before I can add it.

thanks,

greg k-h

2010-11-20 15:53:15

by Greg KH

[permalink] [raw]
Subject: Re: [00/66] 2.6.36.1-stable review

On Sat, Nov 20, 2010 at 09:24:05AM -0500, Andy Lutomirski wrote:
> Greg KH wrote:
>> This is the start of the stable review cycle for the 2.6.36.1 release.
>> There are 66 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with these being applied, please
>> let us know. If anyone is a maintainer of the proper subsystem, and
>> wants to add a Signed-off-by: line to the patch, please respond with it.
>
> Can you add ab838338a2a9e0cb8346eb0cab9977be13e8dce5? (Somehow the cc:
> stable got eaten, but 2.6.36 definitely needs this one. 2.6.35 probably
> does as well but I haven't tested it.)

Please get an ack from the maintainer of that driver and the drm
maintainer so that I can apply it to the next .36 queue.

thanks,

greg k-h

2010-11-22 08:33:38

by Nikola Ciprich

[permalink] [raw]
Subject: Re: [Stable-review] [00/66] 2.6.36.1-stable review

> There's been a lot of patches submitted that didn't make it into .36.1
> due to time constraints and the already-large patch queue size.
>
> I have a lot pending that will show up in .36.2. If you don't see it
> there, please remind me again.
>
> But note, networking patches get sent to me by the network subsystem
> maintainer. Please work with David to get that into the stable tree,
> he's the one who needs to send this to me.
Hi Greg,
Thanks for info. It's surely OK if it gets to 2.6.36.2. David already ACKed
this one (see followup for the linked thread).
cheers
n.



>
> thanks,
>
> greg k-h

--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava

tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799

http://www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------


Attachments:
(No filename) (919.00 B)
(No filename) (198.00 B)
Download all attachments

2010-12-07 20:26:46

by Greg KH

[permalink] [raw]
Subject: Re: [stable] [00/66] 2.6.36.1-stable review

On Sat, Nov 20, 2010 at 07:50:39AM -0800, Greg KH wrote:
> On Sat, Nov 20, 2010 at 04:56:42PM +0100, Thomas Meyer wrote:
> > Am Freitag, den 19.11.2010, 14:03 -0800 schrieb Greg KH:
> > > This is the start of the stable review cycle for the 2.6.36.1 release.
> > > There are 66 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let us know. If anyone is a maintainer of the proper subsystem, and
> > > wants to add a Signed-off-by: line to the patch, please respond with it.
> >
> > This one is missing and crashes my 2.6.36 kernel:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=22922
> >
> > This was fixed in 2.6.37-rc1 in commit: a1c6c5698d53 (ext4: fix
> > NULL pointer dereference in print_daily_error_info())
>
> You need to get the ext4 maintainers to ack that and let me know about
> it before I can add it.

As the ext4 maintainers seem to ignoring the stable trees now for some
reason, I'll just apply this and see who complains :)

thanks,

greg k-h