[patch 00/17] 2.6.27-stable review

[patch 00/17] 2.6.27-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.27.3 release.
There are 17 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.

These patches are sent out with a number of different people on the
Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Wed, October 22, 2008 19: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.27.3-rc1.gz
and the diffstat can be found below.


thanks,

greg k-h

[patch 01/17] fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles

[Greg KH]

[-- Attachment #1: fbcon_set_all_vcs-fix-kernel-crash-when-switching-the-rotated-consoles.patch --]
[-- Type: text/plain, Size: 4014 bytes --]

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

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

From: Oleg Nesterov <oleg@tv-sign.ru>

commit 232fb69a53a5ec3f22a8104d447abe4806848a8f upstream

echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
console. Result:

	BUG: unable to handle kernel paging request at ffffc20005d00000
	IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
	PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
	Oops: 0002 [1] SMP
	CPU 1
	Modules linked in: [...a lot...]
	Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
	RIP: 0010:[bitfill_aligned+149/265]  [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
	RSP: 0018:ffff81007d811bc8  EFLAGS: 00010216
	RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
	RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
	RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
	R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
	R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
	FS:  0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000
	CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
	CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
	Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000)
	Stack:  ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80
	 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
	 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
	Call Trace:
	 [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
	 [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
	 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
	 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
	 [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
	 [redraw_screen+261/481] redraw_screen+0x105/0x1e1
	 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
	 [complete_change_console+48/190] complete_change_console+0x30/0xbe
	 [change_console+115/120] change_console+0x73/0x78
	 [console_callback+0/292] ? console_callback+0x0/0x124
	 [console_callback+97/292] console_callback+0x61/0x124
	 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
	 [run_workqueue+139/282] run_workqueue+0x8b/0x11a
	 [worker_thread+221/238] worker_thread+0xdd/0xee
	 [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
	 [worker_thread+0/238] ? worker_thread+0x0/0xee
	 [kthread+73/118] kthread+0x49/0x76
	 [child_rip+10/18] child_rip+0xa/0x12
	 [kthread+0/118] ? kthread+0x0/0x76
	 [child_rip+0/18] ? child_rip+0x0/0x12

Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
of fbcon_ops->rotate, and vc_resize() has no effect because it is called with
new_cols/rows == ->vc_cols/rows.

Tested on 2.6.26.5-45.fc9.x86_64, but
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
have the same problem.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/console/fbcon.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -2996,8 +2996,8 @@ static void fbcon_set_all_vcs(struct fb_
 		p = &fb_display[vc->vc_num];
 		set_blitting_type(vc, info);
 		var_to_display(p, &info->var, info);
-		cols = FBCON_SWAP(p->rotate, info->var.xres, info->var.yres);
-		rows = FBCON_SWAP(p->rotate, info->var.yres, info->var.xres);
+		cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
+		rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
 		cols /= vc->vc_font.width;
 		rows /= vc->vc_font.height;
 		vc_resize(vc, cols, rows);

-- 

[patch 02/17] modules: fix module "notes" kobject leak

[Greg KH]

[-- Attachment #1: modules-fix-module-notes-kobject-leak.patch --]
[-- Type: text/plain, Size: 1908 bytes --]

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

------------------
From: Alexey Dobriyan <adobriyan@gmail.com>

commit e94320939f44e0cbaccc3f259a5778abced4949c upstream

Fix "notes" kobject leak

It happens every rmmod if KALLSYMS=y and SYSFS=y.

	# modprobe foo

kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module', set: 'module'
kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo', set: '<NULL>'
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo', set: '<NULL>'
	  ^^^^^

	# rmmod foo

kobject: 'holders' (ffff88017e7c5770): kobject_cleanup
kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del
kobject: 'holders' (ffff88017e7c5770): calling ktype release
kobject: (ffff88017e7c5770): dynamic_kobj_release
kobject: 'holders': free name
kobject: 'foo' (ffffffffa00743d0): kobject_cleanup
kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it is broken and must be fixed.
kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del
kobject: 'foo': free name

	[whooops]

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1173,7 +1173,7 @@ static void free_notes_attrs(struct modu
 		while (i-- > 0)
 			sysfs_remove_bin_file(notes_attrs->dir,
 					      &notes_attrs->attrs[i]);
-		kobject_del(notes_attrs->dir);
+		kobject_put(notes_attrs->dir);
 	}
 	kfree(notes_attrs);
 }

-- 

[patch 03/17] Driver core: Fix cleanup in device_create_vargs().

[Greg KH]

[-- Attachment #1: driver-core-fix-cleanup-in-device_create_vargs.patch --]
[-- Type: text/plain, Size: 794 bytes --]

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

------------------
From: Cornelia Huck <cornelia.huck@de.ibm.com>

commit 286661b3777897220ecfcd774bccc68a34667f39 upstream

If device_register() in device_create_vargs() fails, the device
must be cleaned up with put_device() (which is also fine on NULL)
instead of kfree().

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1243,7 +1243,7 @@ struct device *device_create_vargs(struc
 	return dev;
 
 error:
-	kfree(dev);
+	put_device(dev);
 	return ERR_PTR(retval);
 }
 EXPORT_SYMBOL_GPL(device_create_vargs);

-- 

[patch 04/17] Driver core: Clarify device cleanup.

[Greg KH]

[-- Attachment #1: driver-core-clarify-device-cleanup.patch --]
[-- Type: text/plain, Size: 2682 bytes --]

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

------------------
From: Cornelia Huck <cornelia.huck@de.ibm.com>

commit 5739411acbaa63a6c22c91e340fdcdbcc7d82a51 upstream

Make the comments on how to use device_initialize(), device_add()
and device_register() a bit clearer - in particular, explicitly
note that put_device() must be used once we tried to add the device
to the hierarchy.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/core.c |   23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -523,11 +523,16 @@ static void klist_children_put(struct kl
  * device_initialize - init device structure.
  * @dev: device.
  *
- * This prepares the device for use by other layers,
- * including adding it to the device hierarchy.
+ * This prepares the device for use by other layers by initializing
+ * its fields.
  * It is the first half of device_register(), if called by
- * that, though it can also be called separately, so one
- * may use @dev's fields (e.g. the refcount).
+ * that function, though it can also be called separately, so one
+ * may use @dev's fields. In particular, get_device()/put_device()
+ * may be used for reference counting of @dev after calling this
+ * function.
+ *
+ * NOTE: Use put_device() to give up your reference instead of freeing
+ * @dev directly once you have called this function.
  */
 void device_initialize(struct device *dev)
 {
@@ -836,9 +841,13 @@ static void device_remove_sys_dev_entry(
  * This is part 2 of device_register(), though may be called
  * separately _iff_ device_initialize() has been called separately.
  *
- * This adds it to the kobject hierarchy via kobject_add(), adds it
+ * This adds @dev to the kobject hierarchy via kobject_add(), adds it
  * to the global and sibling lists for the device, then
  * adds it to the other relevant subsystems of the driver model.
+ *
+ * NOTE: _Never_ directly free @dev after calling this function, even
+ * if it returned an error! Always use put_device() to give up your
+ * reference instead.
  */
 int device_add(struct device *dev)
 {
@@ -965,6 +974,10 @@ done:
  * I.e. you should only call the two helpers separately if
  * have a clearly defined need to use and refcount the device
  * before it is added to the hierarchy.
+ *
+ * NOTE: _Never_ directly free @dev after calling this function, even
+ * if it returned an error! Always use put_device() to give up the
+ * reference initialized in this function instead.
  */
 int device_register(struct device *dev)
 {

-- 

[patch 05/17] ath9k/mac80211: disallow fragmentation in ath9k, report to userspace

[Greg KH]

[-- Attachment #1: ath9k-mac80211-disallow-fragmentation-in-ath9k-report-to-userspace.patch --]
[-- Type: text/plain, Size: 2106 bytes --]

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

------------------
From: Johannes Berg <johannes@sipsolutions.net>

commit 4233df6b748193d45f79fb7448991a473061a65d upstream

As I've reported, ath9k currently fails utterly when fragmentation
is enabled. This makes ath9k "support" hardware fragmentation by
not supporting fragmentation at all to avoid the double-free issue.
The patch also changes mac80211 to report errors from the driver
operation to userspace.

That hack in ath9k should be removed once the rate control algorithm
it has is fixed, and we can at that time consider removing the hw
fragmentation support entirely since it's not used by any driver.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/ath9k/main.c |    8 +++++++-
 net/mac80211/wext.c               |    2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath9k/main.c
+++ b/drivers/net/wireless/ath9k/main.c
@@ -1007,6 +1007,11 @@ static int ath9k_ampdu_action(struct iee
 	return ret;
 }
 
+static int ath9k_no_fragmentation(struct ieee80211_hw *hw, u32 value)
+{
+	return -EOPNOTSUPP;
+}
+
 static struct ieee80211_ops ath9k_ops = {
 	.tx 		    = ath9k_tx,
 	.start 		    = ath9k_start,
@@ -1031,7 +1036,8 @@ static struct ieee80211_ops ath9k_ops = 
 	.get_tsf 	    = ath9k_get_tsf,
 	.reset_tsf 	    = ath9k_reset_tsf,
 	.tx_last_beacon     = NULL,
-	.ampdu_action       = ath9k_ampdu_action
+	.ampdu_action       = ath9k_ampdu_action,
+	.set_frag_threshold = ath9k_no_fragmentation,
 };
 
 void ath_get_beaconconfig(struct ath_softc *sc,
--- a/net/mac80211/wext.c
+++ b/net/mac80211/wext.c
@@ -804,7 +804,7 @@ static int ieee80211_ioctl_siwfrag(struc
 	 * configure it here */
 
 	if (local->ops->set_frag_threshold)
-		local->ops->set_frag_threshold(
+		return local->ops->set_frag_threshold(
 			local_to_hw(local),
 			local->fragmentation_threshold);
 

-- 

[patch 06/17] md: Fix rdev_size_store with size == 0

[Greg KH]

[-- Attachment #1: md-fix-rdev_size_store-with-size-0.patch --]
[-- Type: text/plain, Size: 1400 bytes --]

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

------------------
From: Chris Webb <chris@arachsys.com>

commit 7d3c6f8717ee6c2bf6cba5fa0bda3b28fbda6015 upstream

Fix rdev_size_store with size == 0.
size == 0 means to use the largest size allowed by the
underlying device and is used when modifying an active array.

This fixes a regression introduced by
 commit d7027458d68b2f1752a28016dcf2ffd0a7e8f567

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/md.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2109,8 +2109,6 @@ rdev_size_store(mdk_rdev_t *rdev, const 
 
 	if (strict_strtoull(buf, 10, &size) < 0)
 		return -EINVAL;
-	if (size < my_mddev->size)
-		return -EINVAL;
 	if (my_mddev->pers && rdev->raid_disk >= 0) {
 		if (my_mddev->persistent) {
 			size = super_types[my_mddev->major_version].
@@ -2121,9 +2119,9 @@ rdev_size_store(mdk_rdev_t *rdev, const 
 			size = (rdev->bdev->bd_inode->i_size >> 10);
 			size -= rdev->data_offset/2;
 		}
-		if (size < my_mddev->size)
-			return -EINVAL; /* component must fit device */
 	}
+	if (size < my_mddev->size)
+		return -EINVAL; /* component must fit device */
 
 	rdev->size = size;
 	if (size > oldsize && my_mddev->external) {

-- 

[patch 07/17] xfs: fix remount rw with unrecognized options

[Greg KH]

[-- Attachment #1: xfs-fix-remount-rw-with-unrecognized-options.patch --]
[-- Type: text/plain, Size: 1345 bytes --]

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

------------------
From: Christoph Hellwig <hch@lst.de>

commit 6c5e51dae2c37127e00be392f40842e08077e96a upstream

When we skip unrecognized options in xfs_fs_remount we should just break
out of the switch and not return because otherwise we may skip clearing
the xfs-internal read-only flag.  This will only show up on some
operations like touch because most read-only checks are done by the VFS
which thinks this filesystem is r/w.  Eventually we should replace the
XFS read-only flag with a helper that always checks the VFS flag to make
sure they can never get out of sync.

Bug reported and fix verified by Marcel Beister on #xfs.
Bug fix verified by updated xfstests/189.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Timothy Shimmin <tes@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/xfs/linux-2.6/xfs_super.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/xfs/linux-2.6/xfs_super.c
+++ b/fs/xfs/linux-2.6/xfs_super.c
@@ -1323,7 +1323,7 @@ xfs_fs_remount(
 	"XFS: mount option \"%s\" not supported for remount\n", p);
 			return -EINVAL;
 #else
-			return 0;
+			break;
 #endif
 		}
 	}

-- 

[patch 08/17] ath9k: fix oops on trying to hold the wrong spinlock

[Greg KH]

[-- Attachment #1: ath9k-fix-oops-on-trying-to-hold-the-wrong-spinlock.patch --]
[-- Type: text/plain, Size: 1288 bytes --]

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

------------------
From: Luis R. Rodriguez <lrodriguez@atheros.com>

commit a477e4e6d48d3ac7c7a75bad40585cb391e5c237 upstream

We were trying to hold the wrong spinlock due to a typo
on IEEE80211_BAR_CTL_TID_S's definition. We use this to
compute the tid number and then hold this this tid number's
spinlock.

Tested-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/ath9k/core.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/ath9k/core.h
+++ b/drivers/net/wireless/ath9k/core.h
@@ -316,7 +316,7 @@ void ath_descdma_cleanup(struct ath_soft
 #define ATH_RX_TIMEOUT           40      /* 40 milliseconds */
 #define WME_NUM_TID              16
 #define IEEE80211_BAR_CTL_TID_M  0xF000  /* tid mask */
-#define IEEE80211_BAR_CTL_TID_S  2       /* tid shift */
+#define IEEE80211_BAR_CTL_TID_S  12      /* tid shift */
 
 enum ATH_RX_TYPE {
 	ATH_RX_NON_CONSUMED = 0,

-- 

[patch 09/17] OHCI: Allow broken controllers to auto-stop

[Greg KH]

[-- Attachment #1: ohci-allow-broken-controllers-to-auto-stop.patch --]
[-- Type: text/plain, Size: 4950 bytes --]

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

------------------
From: Alan Stern <stern@rowland.harvard.edu>

commit 4a511bc3f5829bc18428bcf11c25417a79d09396 upstream

This patch (as1134) attempts to improve the way we handle OHCI
controllers with broken Root Hub Status Change interrupt support.  In
these controllers the RHSC interrupt bit essentially never turns off,
making RHSC interrupts useless -- they have to remain permanently
disabled.

Such controllers should still be allowed to turn off their root hubs
when no devices are attached.  Polling for new connections can
continue while the root hub is suspended.  The patch implements this
feature.  (It won't have much effect unless CONFIG_PM is enabled and
CONFIG_USB_SUSPEND is disabled, but since the overhead is very small
we may as well do it.)

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ohci-hub.c |   60 +++++++++++++++++++++++---------------------
 1 file changed, 32 insertions(+), 28 deletions(-)

--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -362,18 +362,23 @@ static int ohci_root_hub_state_changes(s
 		int any_connected)
 {
 	int	poll_rh = 1;
-	int	rhsc;
+	int	rhsc_status, rhsc_enable;
 
-	rhsc = ohci_readl(ohci, &ohci->regs->intrenable) & OHCI_INTR_RHSC;
-	switch (ohci->hc_control & OHCI_CTRL_HCFS) {
+	/* Some broken controllers never turn off RHCS in the interrupt
+	 * status register.  For their sake we won't re-enable RHSC
+	 * interrupts if the interrupt bit is already active.
+	 */
+	rhsc_status = ohci_readl(ohci, &ohci->regs->intrstatus) &
+			OHCI_INTR_RHSC;
+	rhsc_enable = ohci_readl(ohci, &ohci->regs->intrenable) &
+			OHCI_INTR_RHSC;
 
+	switch (ohci->hc_control & OHCI_CTRL_HCFS) {
 	case OHCI_USB_OPER:
-		/* If no status changes are pending, enable status-change
-		 * interrupts.
-		 */
-		if (!rhsc && !changed) {
-			rhsc = OHCI_INTR_RHSC;
-			ohci_writel(ohci, rhsc, &ohci->regs->intrenable);
+		/* If no status changes are pending, enable RHSC interrupts. */
+		if (!rhsc_enable && !rhsc_status && !changed) {
+			rhsc_enable = OHCI_INTR_RHSC;
+			ohci_writel(ohci, rhsc_enable, &ohci->regs->intrenable);
 		}
 
 		/* Keep on polling until we know a device is connected
@@ -383,7 +388,7 @@ static int ohci_root_hub_state_changes(s
 			if (any_connected ||
 					!device_may_wakeup(&ohci_to_hcd(ohci)
 						->self.root_hub->dev)) {
-				if (rhsc)
+				if (rhsc_enable)
 					poll_rh = 0;
 			} else {
 				ohci->autostop = 1;
@@ -396,34 +401,36 @@ static int ohci_root_hub_state_changes(s
 				ohci->autostop = 0;
 				ohci->next_statechange = jiffies +
 						STATECHANGE_DELAY;
-			} else if (rhsc && time_after_eq(jiffies,
+			} else if (time_after_eq(jiffies,
 						ohci->next_statechange)
 					&& !ohci->ed_rm_list
 					&& !(ohci->hc_control &
 						OHCI_SCHED_ENABLES)) {
 				ohci_rh_suspend(ohci, 1);
-				poll_rh = 0;
+				if (rhsc_enable)
+					poll_rh = 0;
 			}
 		}
 		break;
 
-	/* if there is a port change, autostart or ask to be resumed */
 	case OHCI_USB_SUSPEND:
 	case OHCI_USB_RESUME:
+		/* if there is a port change, autostart or ask to be resumed */
 		if (changed) {
 			if (ohci->autostop)
 				ohci_rh_resume(ohci);
 			else
 				usb_hcd_resume_root_hub(ohci_to_hcd(ohci));
 		} else {
-			if (!rhsc && (ohci->autostop ||
+			if (!rhsc_enable && !rhsc_status && (ohci->autostop ||
 					ohci_to_hcd(ohci)->self.root_hub->
-						do_remote_wakeup))
-				ohci_writel(ohci, OHCI_INTR_RHSC,
+						do_remote_wakeup)) {
+				rhsc_enable = OHCI_INTR_RHSC;
+				ohci_writel(ohci, rhsc_enable,
 						&ohci->regs->intrenable);
-
-			/* everything is idle, no need for polling */
-			poll_rh = 0;
+			}
+			if (rhsc_enable)
+				poll_rh = 0;
 		}
 		break;
 	}
@@ -443,12 +450,16 @@ static inline int ohci_rh_resume(struct 
 static int ohci_root_hub_state_changes(struct ohci_hcd *ohci, int changed,
 		int any_connected)
 {
+	int	rhsc_status;
+
 	/* If RHSC is enabled, don't poll */
 	if (ohci_readl(ohci, &ohci->regs->intrenable) & OHCI_INTR_RHSC)
 		return 0;
 
-	/* If no status changes are pending, enable status-change interrupts */
-	if (!changed) {
+	/* If no status changes are pending, enable RHSC interrupts */
+	rhsc_status = ohci_readl(ohci, &ohci->regs->intrstatus) &
+			OHCI_INTR_RHSC;
+	if (!changed && !rhsc_status) {
 		ohci_writel(ohci, OHCI_INTR_RHSC, &ohci->regs->intrenable);
 		return 0;
 	}
@@ -492,13 +503,6 @@ ohci_hub_status_data (struct usb_hcd *hc
 		length++;
 	}
 
-	/* Some broken controllers never turn off RHCS in the interrupt
-	 * status register.  For their sake we won't re-enable RHSC
-	 * interrupts if the flag is already set.
-	 */
-	if (ohci_readl(ohci, &ohci->regs->intrstatus) & OHCI_INTR_RHSC)
-		changed = 1;
-
 	/* look at each port */
 	for (i = 0; i < ohci->num_ports; i++) {
 		u32	status = roothub_portstatus (ohci, i);

-- 

[patch 10/17] USB: OHCI: fix endless polling behavior

[Greg KH]

[-- Attachment #1: usb-ohci-fix-endless-polling-behavior.patch --]
[-- Type: text/plain, Size: 5417 bytes --]

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

------------------
From: Alan Stern <stern@rowland.harvard.edu>

commit 71b7497c078a97e2afb774ad7c1f8ff5bdda8a60 upstream

This patch (as1149) fixes an obscure problem in OHCI polling.  In the
current code, if the RHSC interrupt status flag turns on at a time
when RHSC interrupts are disabled, it will remain on forever:

	The interrupt handler is the only place where RHSC status
	gets turned back off;

	The interrupt handler won't turn RHSC status off because it
	doesn't turn off status flags if the corresponding interrupt
	isn't enabled;

	RHSC interrupts will never get enabled because
	ohci_root_hub_state_changes() doesn't reenable RHSC if RHSC
	status is on!

As a result we will continue polling indefinitely instead of reverting
to interrupt-driven operation, and the root hub will not autosuspend.
This particular sequence of events is not at all unusual; in fact
plugging a USB device into an OHCI controller will usually cause it to
occur.

Of course, this is a bug.  The proper thing to do is to turn off RHSC
status just before reading the actual port status values.  That way
either a port status change will be detected (if it occurs before the
status read) or it will turn RHSC back on.  Possibly both, but that
won't hurt anything.

We can still check for systems in which RHSC is totally broken, by
re-reading RHSC after clearing it and before reading the port
statuses.  (This re-read has to be done anyway, to post the earlier
write.)  If RHSC is on but no port-change statuses are set, then we
know that RHSC is broken and we can avoid re-enabling it.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ohci-hub.c |   51 +++++++++++++++++++++++++++-----------------
 1 file changed, 32 insertions(+), 19 deletions(-)

--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -359,17 +359,15 @@ static void ohci_finish_controller_resum
 
 /* Carry out polling-, autostop-, and autoresume-related state changes */
 static int ohci_root_hub_state_changes(struct ohci_hcd *ohci, int changed,
-		int any_connected)
+		int any_connected, int rhsc_status)
 {
 	int	poll_rh = 1;
-	int	rhsc_status, rhsc_enable;
+	int	rhsc_enable;
 
 	/* Some broken controllers never turn off RHCS in the interrupt
 	 * status register.  For their sake we won't re-enable RHSC
 	 * interrupts if the interrupt bit is already active.
 	 */
-	rhsc_status = ohci_readl(ohci, &ohci->regs->intrstatus) &
-			OHCI_INTR_RHSC;
 	rhsc_enable = ohci_readl(ohci, &ohci->regs->intrenable) &
 			OHCI_INTR_RHSC;
 
@@ -421,14 +419,23 @@ static int ohci_root_hub_state_changes(s
 				ohci_rh_resume(ohci);
 			else
 				usb_hcd_resume_root_hub(ohci_to_hcd(ohci));
+
+		/* If remote wakeup is disabled, stop polling */
+		} else if (!ohci->autostop &&
+				!ohci_to_hcd(ohci)->self.root_hub->
+					do_remote_wakeup) {
+			poll_rh = 0;
+
 		} else {
-			if (!rhsc_enable && !rhsc_status && (ohci->autostop ||
-					ohci_to_hcd(ohci)->self.root_hub->
-						do_remote_wakeup)) {
+			/* If no status changes are pending,
+			 * enable RHSC interrupts
+			 */
+			if (!rhsc_enable && !rhsc_status) {
 				rhsc_enable = OHCI_INTR_RHSC;
 				ohci_writel(ohci, rhsc_enable,
 						&ohci->regs->intrenable);
 			}
+			/* Keep polling until RHSC is enabled */
 			if (rhsc_enable)
 				poll_rh = 0;
 		}
@@ -448,22 +455,22 @@ static inline int ohci_rh_resume(struct 
  * autostop isn't used when CONFIG_PM is turned off.
  */
 static int ohci_root_hub_state_changes(struct ohci_hcd *ohci, int changed,
-		int any_connected)
+		int any_connected, int rhsc_status)
 {
-	int	rhsc_status;
-
 	/* If RHSC is enabled, don't poll */
 	if (ohci_readl(ohci, &ohci->regs->intrenable) & OHCI_INTR_RHSC)
 		return 0;
 
-	/* If no status changes are pending, enable RHSC interrupts */
-	rhsc_status = ohci_readl(ohci, &ohci->regs->intrstatus) &
-			OHCI_INTR_RHSC;
-	if (!changed && !rhsc_status) {
-		ohci_writel(ohci, OHCI_INTR_RHSC, &ohci->regs->intrenable);
-		return 0;
-	}
-	return 1;
+	/* If status changes are pending, continue polling.
+	 * Conversely, if no status changes are pending but the RHSC
+	 * status bit was set, then RHSC may be broken so continue polling.
+	 */
+	if (changed || rhsc_status)
+		return 1;
+
+	/* It's safe to re-enable RHSC interrupts */
+	ohci_writel(ohci, OHCI_INTR_RHSC, &ohci->regs->intrenable);
+	return 0;
 }
 
 #endif	/* CONFIG_PM */
@@ -478,6 +485,7 @@ ohci_hub_status_data (struct usb_hcd *hc
 	struct ohci_hcd	*ohci = hcd_to_ohci (hcd);
 	int		i, changed = 0, length = 1;
 	int		any_connected = 0;
+	int		rhsc_status;
 	unsigned long	flags;
 
 	spin_lock_irqsave (&ohci->lock, flags);
@@ -503,6 +511,11 @@ ohci_hub_status_data (struct usb_hcd *hc
 		length++;
 	}
 
+	/* Clear the RHSC status flag before reading the port statuses */
+	ohci_writel(ohci, OHCI_INTR_RHSC, &ohci->regs->intrstatus);
+	rhsc_status = ohci_readl(ohci, &ohci->regs->intrstatus) &
+			OHCI_INTR_RHSC;
+
 	/* look at each port */
 	for (i = 0; i < ohci->num_ports; i++) {
 		u32	status = roothub_portstatus (ohci, i);
@@ -521,7 +534,7 @@ ohci_hub_status_data (struct usb_hcd *hc
 	}
 
 	hcd->poll_rh = ohci_root_hub_state_changes(ohci, changed,
-			any_connected);
+			any_connected, rhsc_status);
 
 done:
 	spin_unlock_irqrestore (&ohci->lock, flags);

-- 

[patch 11/17] USB: Fix s3c2410_udc usb speed handling

[Greg KH]

[-- Attachment #1: usb-fix-s3c2410_udc-usb-speed-handling.patch --]
[-- Type: text/plain, Size: 1191 bytes --]

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

------------------
From: Yauhen Kharuzhy <jekhor@gmail.com>

commit f9e9cff613b8239ce9159735aa662c9c85b478bf upstream

The new composite framework revealed a weakness in the
s3c2410_udc driver gadget register function. Instead of
checking if speed asked for was USB_LOW_SPEED upon
usb_gadget_register() to deny service, it checked only
for USB_FULL_SPEED, thus denying service to usb high
speed capable gadgets (like g_ether).

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/usb/gadget/s3c2410_udc.c
+++ b/drivers/usb/gadget/s3c2410_udc.c
@@ -1651,7 +1651,7 @@ int usb_gadget_register_driver(struct us
 		return -EBUSY;
 
 	if (!driver->bind || !driver->setup
-			|| driver->speed != USB_SPEED_FULL) {
+			|| driver->speed < USB_SPEED_FULL) {
 		printk(KERN_ERR "Invalid driver: bind %p setup %p speed %d\n",
 			driver->bind, driver->setup, driver->speed);
 		return -EINVAL;

-- 

[patch 12/17] USB: EHCI: log a warning if ehci-hcd is not loaded first

[Greg KH]

[-- Attachment #1: usb-ehci-log-a-warning-if-ehci-hcd-is-not-loaded-first.patch --]
[-- Type: text/plain, Size: 4351 bytes --]

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

------------------
From: Alan Stern <stern@rowland.harvard.edu>

commit 9beeee6584b9aa4f9192055512411484a2a624df upstream

This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd.  Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/hcd.c      |    4 ++++
 drivers/usb/core/hcd.h      |    6 ++++++
 drivers/usb/host/ehci-hcd.c |   15 +++++++++++++--
 drivers/usb/host/ohci-hcd.c |    3 +++
 drivers/usb/host/uhci-hcd.c |    3 +++
 5 files changed, 29 insertions(+), 2 deletions(-)

--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -81,6 +81,10 @@
 
 /*-------------------------------------------------------------------------*/
 
+/* Keep track of which host controller drivers are loaded */
+unsigned long usb_hcds_loaded;
+EXPORT_SYMBOL_GPL(usb_hcds_loaded);
+
 /* host controllers we manage */
 LIST_HEAD (usb_bus_list);
 EXPORT_SYMBOL_GPL (usb_bus_list);
--- a/drivers/usb/core/hcd.h
+++ b/drivers/usb/core/hcd.h
@@ -482,4 +482,10 @@ static inline void usbmon_urb_complete(s
  */
 extern struct rw_semaphore ehci_cf_port_reset_rwsem;
 
+/* Keep track of which host controller drivers are loaded */
+#define USB_UHCI_LOADED		0
+#define USB_OHCI_LOADED		1
+#define USB_EHCI_LOADED		2
+extern unsigned long usb_hcds_loaded;
+
 #endif /* __KERNEL__ */
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1049,6 +1049,12 @@ static int __init ehci_hcd_init(void)
 {
 	int retval = 0;
 
+	set_bit(USB_EHCI_LOADED, &usb_hcds_loaded);
+	if (test_bit(USB_UHCI_LOADED, &usb_hcds_loaded) ||
+			test_bit(USB_OHCI_LOADED, &usb_hcds_loaded))
+		printk(KERN_WARNING "Warning! ehci_hcd should always be loaded"
+				" before uhci_hcd and ohci_hcd, not after\n");
+
 	pr_debug("%s: block sizes: qh %Zd qtd %Zd itd %Zd sitd %Zd\n",
 		 hcd_name,
 		 sizeof(struct ehci_qh), sizeof(struct ehci_qtd),
@@ -1056,8 +1062,10 @@ static int __init ehci_hcd_init(void)
 
 #ifdef DEBUG
 	ehci_debug_root = debugfs_create_dir("ehci", NULL);
-	if (!ehci_debug_root)
-		return -ENOENT;
+	if (!ehci_debug_root) {
+		retval = -ENOENT;
+		goto err_debug;
+	}
 #endif
 
 #ifdef PLATFORM_DRIVER
@@ -1104,7 +1112,9 @@ clean0:
 #ifdef DEBUG
 	debugfs_remove(ehci_debug_root);
 	ehci_debug_root = NULL;
+err_debug:
 #endif
+	clear_bit(USB_EHCI_LOADED, &usb_hcds_loaded);
 	return retval;
 }
 module_init(ehci_hcd_init);
@@ -1126,6 +1136,7 @@ static void __exit ehci_hcd_cleanup(void
 #ifdef DEBUG
 	debugfs_remove(ehci_debug_root);
 #endif
+	clear_bit(USB_EHCI_LOADED, &usb_hcds_loaded);
 }
 module_exit(ehci_hcd_cleanup);
 
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1098,6 +1098,7 @@ static int __init ohci_hcd_mod_init(void
 	printk (KERN_DEBUG "%s: " DRIVER_INFO "\n", hcd_name);
 	pr_debug ("%s: block sizes: ed %Zd td %Zd\n", hcd_name,
 		sizeof (struct ed), sizeof (struct td));
+	set_bit(USB_OHCI_LOADED, &usb_hcds_loaded);
 
 #ifdef DEBUG
 	ohci_debug_root = debugfs_create_dir("ohci", NULL);
@@ -1184,6 +1185,7 @@ static int __init ohci_hcd_mod_init(void
  error_debug:
 #endif
 
+	clear_bit(USB_OHCI_LOADED, &usb_hcds_loaded);
 	return retval;
 }
 module_init(ohci_hcd_mod_init);
@@ -1214,6 +1216,7 @@ static void __exit ohci_hcd_mod_exit(voi
 #ifdef DEBUG
 	debugfs_remove(ohci_debug_root);
 #endif
+	clear_bit(USB_OHCI_LOADED, &usb_hcds_loaded);
 }
 module_exit(ohci_hcd_mod_exit);
 
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -953,6 +953,7 @@ static int __init uhci_hcd_init(void)
 
 	printk(KERN_INFO DRIVER_DESC " " DRIVER_VERSION "%s\n",
 			ignore_oc ? ", overcurrent ignored" : "");
+	set_bit(USB_UHCI_LOADED, &usb_hcds_loaded);
 
 	if (usb_disabled())
 		return -ENODEV;
@@ -988,6 +989,7 @@ debug_failed:
 
 errbuf_failed:
 
+	clear_bit(USB_UHCI_LOADED, &usb_hcds_loaded);
 	return retval;
 }
 
@@ -997,6 +999,7 @@ static void __exit uhci_hcd_cleanup(void
 	kmem_cache_destroy(uhci_up_cachep);
 	debugfs_remove(uhci_debugfs_root);
 	kfree(errbuf);
+	clear_bit(USB_UHCI_LOADED, &usb_hcds_loaded);
 }
 
 module_init(uhci_hcd_init);

-- 

[patch 13/17] usb gadget: cdc ethernet notification bugfix

[Greg KH]

[-- Attachment #1: usb-gadget-cdc-ethernet-notification-bugfix.patch --]
[-- Type: text/plain, Size: 1260 bytes --]

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

------------------
From: David Brownell <dbrownell@users.sourceforge.net>

commit 29bac7b7661bbbdbbd32bc1e6cedca22f260da7f upstream

Bugfix for the new CDC Ethernet code:  as part of activating the
network interface's USB link, make sure its link management code
knows whether the interface is open or not.

Without this fix, the link won't work right when it's brought up
before the link is active ... because the initial notification it
sends will have the wrong link state (down, not up).  Makes it
hard to bridge these links (on the host side), among other things.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -873,6 +873,13 @@ struct net_device *gether_connect(struct
 		spin_lock(&dev->lock);
 		dev->port_usb = link;
 		link->ioport = dev;
+		if (netif_running(dev->net)) {
+			if (link->open)
+				link->open(link);
+		} else {
+			if (link->close)
+				link->close(link);
+		}
 		spin_unlock(&dev->lock);
 
 		netif_carrier_on(dev->net);

-- 

[patch 14/17] usb: musb_hdrc build fixes

[Greg KH]

[-- Attachment #1: usb-musb_hdrc-build-fixes.patch --]
[-- Type: text/plain, Size: 6101 bytes --]

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

------------------
From: David Brownell <dbrownell@users.sourceforge.net>

commit c767c1c6f1febbd1351cc152bba6e37889322d17 upstream

Minor musb_hdrc updates:

  - so it'll build on DaVinci, given relevant platform updates;
      * remove support for an un-shipped OTG prototype
      * rely on gpiolib framework conversion for the I2C GPIOs
      * the <asm/arch/hdrc_cnf.h> mechanism has been removed

  - catch comments up to the recent removal of the per-SOC header
    with the silicon configuration data;

  - and remove two inappropriate "inline" declarations which
    just bloat host side code.

There are still some more <asm/arch/XYZ.h> ==> <mach/XYZ.h>
changes needed in this driver, catching up to the relocation
of most of the include/asm-arm/arch-* contents.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/musb/Kconfig     |    4 ----
 drivers/usb/musb/cppi_dma.h  |    4 ++--
 drivers/usb/musb/davinci.c   |   20 ++++----------------
 drivers/usb/musb/musb_core.c |    8 ++++----
 drivers/usb/musb/musb_host.c |    6 +++---
 5 files changed, 13 insertions(+), 29 deletions(-)

--- a/drivers/usb/musb/cppi_dma.h
+++ b/drivers/usb/musb/cppi_dma.h
@@ -119,8 +119,8 @@ struct cppi {
 	void __iomem			*mregs;		/* Mentor regs */
 	void __iomem			*tibase;	/* TI/CPPI regs */
 
-	struct cppi_channel		tx[MUSB_C_NUM_EPT - 1];
-	struct cppi_channel		rx[MUSB_C_NUM_EPR - 1];
+	struct cppi_channel		tx[4];
+	struct cppi_channel		rx[4];
 
 	struct dma_pool			*pool;
 
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -30,6 +30,7 @@
 #include <linux/delay.h>
 #include <linux/clk.h>
 #include <linux/io.h>
+#include <linux/gpio.h>
 
 #include <asm/arch/hardware.h>
 #include <asm/arch/memory.h>
@@ -39,7 +40,7 @@
 #include "musb_core.h"
 
 #ifdef CONFIG_MACH_DAVINCI_EVM
-#include <asm/arch/i2c-client.h>
+#define GPIO_nVBUS_DRV		87
 #endif
 
 #include "davinci.h"
@@ -138,7 +139,6 @@ static int vbus_state = -1;
 /* VBUS SWITCHING IS BOARD-SPECIFIC */
 
 #ifdef CONFIG_MACH_DAVINCI_EVM
-#ifndef CONFIG_MACH_DAVINCI_EVM_OTG
 
 /* I2C operations are always synchronous, and require a task context.
  * With unloaded systems, using the shared workqueue seems to suffice
@@ -146,12 +146,11 @@ static int vbus_state = -1;
  */
 static void evm_deferred_drvvbus(struct work_struct *ignored)
 {
-	davinci_i2c_expander_op(0x3a, USB_DRVVBUS, vbus_state);
+	gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
 	vbus_state = !vbus_state;
 }
 static DECLARE_WORK(evm_vbus_work, evm_deferred_drvvbus);
 
-#endif	/* modified board */
 #endif	/* EVM */
 
 static void davinci_source_power(struct musb *musb, int is_on, int immediate)
@@ -165,21 +164,10 @@ static void davinci_source_power(struct 
 
 #ifdef CONFIG_MACH_DAVINCI_EVM
 	if (machine_is_davinci_evm()) {
-#ifdef CONFIG_MACH_DAVINCI_EVM_OTG
-		/* modified EVM board switching VBUS with GPIO(6) not I2C
-		 * NOTE:  PINMUX0.RGB888 (bit23) must be clear
-		 */
-		if (is_on)
-			gpio_set(GPIO(6));
-		else
-			gpio_clear(GPIO(6));
-		immediate = 1;
-#else
 		if (immediate)
-			davinci_i2c_expander_op(0x3a, USB_DRVVBUS, !is_on);
+			gpio_set_value_cansleep(GPIO_nVBUS_DRV, vbus_state);
 		else
 			schedule_work(&evm_vbus_work);
-#endif
 	}
 #endif
 	if (immediate)
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -33,10 +33,6 @@ config USB_MUSB_SOC
 	default y if ARCH_DAVINCI
 	default y if ARCH_OMAP2430
 	default y if ARCH_OMAP34XX
-	help
-	  Use a static <asm/arch/hdrc_cnf.h> file to describe how the
-	  controller is configured (endpoints, mechanisms, etc) on the
-	  current iteration of a given system-on-chip.
 
 comment "DaVinci 644x USB support"
 	depends on USB_MUSB_HDRC && ARCH_DAVINCI
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -82,9 +82,9 @@
 /*
  * This gets many kinds of configuration information:
  *	- Kconfig for everything user-configurable
- *	- <asm/arch/hdrc_cnf.h> for SOC or family details
  *	- platform_device for addressing, irq, and platform_data
  *	- platform_data is mostly for board-specific informarion
+ *	  (plus recentrly, SOC or family details)
  *
  * Most of the conditional compilation will (someday) vanish.
  */
@@ -974,9 +974,9 @@ static void musb_shutdown(struct platfor
 /*
  * The silicon either has hard-wired endpoint configurations, or else
  * "dynamic fifo" sizing.  The driver has support for both, though at this
- * writing only the dynamic sizing is very well tested.   We use normal
- * idioms to so both modes are compile-tested, but dead code elimination
- * leaves only the relevant one in the object file.
+ * writing only the dynamic sizing is very well tested.   Since we switched
+ * away from compile-time hardware parameters, we can no longer rely on
+ * dead code elimination to leave only the relevant one in the object file.
  *
  * We don't currently use dynamic fifo setup capability to do anything
  * more than selecting one of a bunch of predefined configurations.
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -108,7 +108,7 @@ static void musb_ep_program(struct musb 
 /*
  * Clear TX fifo. Needed to avoid BABBLE errors.
  */
-static inline void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
+static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep)
 {
 	void __iomem	*epio = ep->regs;
 	u16		csr;
@@ -436,7 +436,7 @@ musb_advance_schedule(struct musb *musb,
 	}
 }
 
-static inline u16 musb_h_flush_rxfifo(struct musb_hw_ep *hw_ep, u16 csr)
+static u16 musb_h_flush_rxfifo(struct musb_hw_ep *hw_ep, u16 csr)
 {
 	/* we don't want fifo to fill itself again;
 	 * ignore dma (various models),
@@ -1005,7 +1005,7 @@ static bool musb_h_ep0_continue(struct m
 
 /*
  * Handle default endpoint interrupt as host. Only called in IRQ time
- * from the LinuxIsr() interrupt service routine.
+ * from musb_interrupt().
  *
  * called with controller irqlocked
  */

-- 

[patch 15/17] drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)

[Greg KH]

[-- Attachment #1: drm-i915-fix-ioremap-of-a-user-address-for-non-root.patch --]
[-- Type: text/plain, Size: 1472 bytes --]

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

------------------
From: Matthias Hopf <mhopf@suse.de>

commit 4b40893918203ee1a1f6a114316c2a19c072e9bd upstream

Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.

It only affects the Intel G33 series and newer.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/gpu/drm/i915/i915_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -836,7 +836,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
 	DRM_IOCTL_DEF(DRM_I915_SET_VBLANK_PIPE,  i915_vblank_pipe_set, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY ),
 	DRM_IOCTL_DEF(DRM_I915_GET_VBLANK_PIPE,  i915_vblank_pipe_get, DRM_AUTH ),
 	DRM_IOCTL_DEF(DRM_I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
-	DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page, DRM_AUTH),
+	DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 };
 
 int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);

-- 

[patch 16/17] DVB: au0828: add support for another USB id for Hauppauge HVR950Q

[Greg KH]

[-- Attachment #1: dvb-au0828-add-support-for-another-usb-id-for-hauppauge-hvr950q.patch --]
[-- Type: text/plain, Size: 2398 bytes --]

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

------------------
From: Michael Krufky <mkrufky@linuxtv.org>

(cherry picked from commit a636da6bab3307fc8c6e6a22a63b0b25ba0687be)

DVB: au0828: add support for another USB id for Hauppauge HVR950Q

Add autodetection support for a new revision of the Hauppauge HVR950Q (2040:721e)

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/video4linux/CARDLIST.au0828 |    2 +-
 drivers/media/video/au0828/au0828-cards.c |    3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

--- a/Documentation/video4linux/CARDLIST.au0828
+++ b/Documentation/video4linux/CARDLIST.au0828
@@ -1,5 +1,5 @@
   0 -> Unknown board                            (au0828)
-  1 -> Hauppauge HVR950Q                        (au0828)        [2040:7200,2040:7210,2040:7217,2040:721b,2040:721f,2040:7280,0fd9:0008]
+  1 -> Hauppauge HVR950Q                        (au0828)        [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008]
   2 -> Hauppauge HVR850                         (au0828)        [2040:7240]
   3 -> DViCO FusionHDTV USB                     (au0828)        [0fe9:d620]
   4 -> Hauppauge HVR950Q rev xxF8               (au0828)        [2040:7201,2040:7211,2040:7281]
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -90,6 +90,7 @@ static void hauppauge_eeprom(struct au08
 	case 72221: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and basic analog video */
 	case 72231: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and basic analog video */
 	case 72241: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM and basic analog video */
+	case 72251: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and basic analog video */
 	case 72301: /* WinTV-HVR850 (Retail, IR, ATSC and basic analog video */
 	case 72500: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM */
 		break;
@@ -198,6 +199,8 @@ struct usb_device_id au0828_usb_id_table
 		.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q },
 	{ USB_DEVICE(0x2040, 0x721b),
 		.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q },
+	{ USB_DEVICE(0x2040, 0x721e),
+		.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q },
 	{ USB_DEVICE(0x2040, 0x721f),
 		.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q },
 	{ USB_DEVICE(0x2040, 0x7280),

-- 

[patch 17/17] DVB: sms1xxx: support two new revisions of the Hauppauge WinTV MiniStick

[Greg KH]

[-- Attachment #1: dvb-sms1xxx-support-two-new-revisions-of-the-hauppauge-wintv-ministick.patch --]
[-- Type: text/plain, Size: 1176 bytes --]


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

------------------
From: Michael Krufky <mkrufky@linuxtv.org>

(cherry picked from commit 3dfbe31f09fb1da5f17437fd384cdfb6114765d9)

DVB: sms1xxx: support two new revisions of the Hauppauge WinTV MiniStick

Autodetect 2040:5520 and 2040:5530 as Hauppauge WinTV MiniStick

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/dvb/siano/sms-cards.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -42,6 +42,10 @@ struct usb_device_id smsusb_id_table[] =
 		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 	{ USB_DEVICE(0x2040, 0x5510),
 		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+	{ USB_DEVICE(0x2040, 0x5520),
+		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
+	{ USB_DEVICE(0x2040, 0x5530),
+		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 	{ USB_DEVICE(0x2040, 0x5580),
 		.driver_info = SMS1XXX_BOARD_HAUPPAUGE_WINDHAM },
 	{ USB_DEVICE(0x2040, 0x5590),

-- 

Re: [patch 00/17] 2.6.27-stable review

[Greg KH]

On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.27.3-rc1.gz
> and the diffstat can be found below.

Oops, forgot it, here it is.

 Documentation/video4linux/CARDLIST.au0828 |    2 
 Makefile                                  |    2 
 drivers/base/core.c                       |   25 ++++++--
 drivers/gpu/drm/i915/i915_dma.c           |    2 
 drivers/md/md.c                           |    6 --
 drivers/media/dvb/siano/sms-cards.c       |    4 +
 drivers/media/video/au0828/au0828-cards.c |    3 +
 drivers/net/wireless/ath9k/core.h         |    2 
 drivers/net/wireless/ath9k/main.c         |    8 ++
 drivers/usb/core/hcd.c                    |    4 +
 drivers/usb/core/hcd.h                    |    6 ++
 drivers/usb/gadget/s3c2410_udc.c          |    2 
 drivers/usb/gadget/u_ether.c              |    7 ++
 drivers/usb/host/ehci-hcd.c               |   15 ++++-
 drivers/usb/host/ohci-hcd.c               |    3 +
 drivers/usb/host/ohci-hub.c               |   87 +++++++++++++++++-------------
 drivers/usb/host/uhci-hcd.c               |    3 +
 drivers/usb/musb/Kconfig                  |    4 -
 drivers/usb/musb/cppi_dma.h               |    4 -
 drivers/usb/musb/davinci.c                |   20 +-----
 drivers/usb/musb/musb_core.c              |    8 +-
 drivers/usb/musb/musb_host.c              |    6 +-
 drivers/video/console/fbcon.c             |    4 -
 fs/xfs/linux-2.6/xfs_super.c              |    2 
 kernel/module.c                           |    2 
 net/mac80211/wext.c                       |    2 
 26 files changed, 146 insertions(+), 87 deletions(-)

Re: [patch 00/17] 2.6.27-stable review

[Josh Boyer]

On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
>This is the start of the stable review cycle for the 2.6.27.3 release.
>There are 17 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.
>
>These patches are sent out with a number of different people on the
>Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
>to add your name to the list.  If you want to be off the reviewer list,
>also email us.
>
>Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
>Anything received after that time might be too late.

OK, I realize I'm late.  Apologies in advance for that.

I don't see how patches 3, 16, and 17 really fit into the "stable"
rules.  None of them:

"... fix a problem that causes a build error (but not for things
 marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
 security issue, or some "oh, that's not good" issue.  In short,
 something critical."

So, are we being a bit more lax on the requirements for the
-stable kernels and I missed the memo, or?

josh

Re: [stable] [patch 00/17] 2.6.27-stable review

[Greg KH]

On Wed, Oct 22, 2008 at 09:01:26PM -0400, Josh Boyer wrote:
> On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
> >This is the start of the stable review cycle for the 2.6.27.3 release.
> >There are 17 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.
> >
> >These patches are sent out with a number of different people on the
> >Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
> >to add your name to the list.  If you want to be off the reviewer list,
> >also email us.
> >
> >Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
> >Anything received after that time might be too late.
> 
> OK, I realize I'm late.  Apologies in advance for that.
> 
> I don't see how patches 3, 16, and 17 really fit into the "stable"
> rules.  None of them:
> 
> "... fix a problem that causes a build error (but not for things
>  marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>  security issue, or some "oh, that's not good" issue.  In short,
>  something critical."
> 
> So, are we being a bit more lax on the requirements for the
> -stable kernels and I missed the memo, or?

Huh?

Patch 3:
	Driver core: Fix cleanup in device_create_vargs().
solves a memory leak on an error path that has every opportunity to
happen in the driver core.  Do you think this is not a real bug?

Patch 16 and 17 add new device ids, something that we started allowing
in -stable trees a number of major releases ago.  You missed the memo
for that one :)

Perhaps we need to add it to the file
Documentation/stable_kernel_rules.txt, anyone care to send a patch?

thanks,

greg k-h

Re: [stable] [patch 00/17] 2.6.27-stable review

[Josh Boyer]

On Wed, 22 Oct 2008 21:53:45 -0700
Greg KH <greg@kroah.com> wrote:

> On Wed, Oct 22, 2008 at 09:01:26PM -0400, Josh Boyer wrote:
> > On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
> > >This is the start of the stable review cycle for the 2.6.27.3 release.
> > >There are 17 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.
> > >
> > >These patches are sent out with a number of different people on the
> > >Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
> > >to add your name to the list.  If you want to be off the reviewer list,
> > >also email us.
> > >
> > >Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
> > >Anything received after that time might be too late.
> > 
> > OK, I realize I'm late.  Apologies in advance for that.
> > 
> > I don't see how patches 3, 16, and 17 really fit into the "stable"
> > rules.  None of them:
> > 
> > "... fix a problem that causes a build error (but not for things
> >  marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> >  security issue, or some "oh, that's not good" issue.  In short,
> >  something critical."
> > 
> > So, are we being a bit more lax on the requirements for the
> > -stable kernels and I missed the memo, or?
> 
> Huh?
> 
> Patch 3:
> 	Driver core: Fix cleanup in device_create_vargs().
> solves a memory leak on an error path that has every opportunity to
> happen in the driver core.  Do you think this is not a real bug?

Grr..  Typo on my part.  Patch 4 is the one I originally meant:
"Driver Core: Clarify device cleanup." It changes nothing but
comments.  I don't think it's a big deal at all, but are documentation
changes also allowed now?

> Patch 16 and 17 add new device ids, something that we started allowing
> in -stable trees a number of major releases ago.  You missed the memo
> for that one :)
> 
> Perhaps we need to add it to the file
> Documentation/stable_kernel_rules.txt, anyone care to send a patch?

Will do as soon as I get an answer to the question above.

josh

Re: [stable] [patch 00/17] 2.6.27-stable review

[Greg KH]

On Thu, Oct 23, 2008 at 06:33:39AM -0400, Josh Boyer wrote:
> On Wed, 22 Oct 2008 21:53:45 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > On Wed, Oct 22, 2008 at 09:01:26PM -0400, Josh Boyer wrote:
> > > On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
> > > >This is the start of the stable review cycle for the 2.6.27.3 release.
> > > >There are 17 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.
> > > >
> > > >These patches are sent out with a number of different people on the
> > > >Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
> > > >to add your name to the list.  If you want to be off the reviewer list,
> > > >also email us.
> > > >
> > > >Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
> > > >Anything received after that time might be too late.
> > > 
> > > OK, I realize I'm late.  Apologies in advance for that.
> > > 
> > > I don't see how patches 3, 16, and 17 really fit into the "stable"
> > > rules.  None of them:
> > > 
> > > "... fix a problem that causes a build error (but not for things
> > >  marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> > >  security issue, or some "oh, that's not good" issue.  In short,
> > >  something critical."
> > > 
> > > So, are we being a bit more lax on the requirements for the
> > > -stable kernels and I missed the memo, or?
> > 
> > Huh?
> > 
> > Patch 3:
> > 	Driver core: Fix cleanup in device_create_vargs().
> > solves a memory leak on an error path that has every opportunity to
> > happen in the driver core.  Do you think this is not a real bug?
> 
> Grr..  Typo on my part.  Patch 4 is the one I originally meant:
> "Driver Core: Clarify device cleanup." It changes nothing but
> comments.  I don't think it's a big deal at all, but are documentation
> changes also allowed now?

It was a documentation change, fixing the information for a core API
call to be correct and match what the code really does.

It also carried no risk of a regression, and as such, I decided to take
it.  If you note, we have also taken other patches that fix up
documentation issues like this in the past, so it was not the first
time.

Was this that big of a deal?

thanks,

greg k-h

Re: [stable] [patch 00/17] 2.6.27-stable review

[Josh Boyer]

On Thu, 23 Oct 2008 08:33:48 -0700
Greg KH <greg@kroah.com> wrote:

> On Thu, Oct 23, 2008 at 06:33:39AM -0400, Josh Boyer wrote:
> > On Wed, 22 Oct 2008 21:53:45 -0700
> > Greg KH <greg@kroah.com> wrote:
> > 
> > > On Wed, Oct 22, 2008 at 09:01:26PM -0400, Josh Boyer wrote:
> > > > On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
> > > > >This is the start of the stable review cycle for the 2.6.27.3 release.
> > > > >There are 17 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.
> > > > >
> > > > >These patches are sent out with a number of different people on the
> > > > >Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
> > > > >to add your name to the list.  If you want to be off the reviewer list,
> > > > >also email us.
> > > > >
> > > > >Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
> > > > >Anything received after that time might be too late.
> > > > 
> > > > OK, I realize I'm late.  Apologies in advance for that.
> > > > 
> > > > I don't see how patches 3, 16, and 17 really fit into the "stable"
> > > > rules.  None of them:
> > > > 
> > > > "... fix a problem that causes a build error (but not for things
> > > >  marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> > > >  security issue, or some "oh, that's not good" issue.  In short,
> > > >  something critical."
> > > > 
> > > > So, are we being a bit more lax on the requirements for the
> > > > -stable kernels and I missed the memo, or?
> > > 
> > > Huh?
> > > 
> > > Patch 3:
> > > 	Driver core: Fix cleanup in device_create_vargs().
> > > solves a memory leak on an error path that has every opportunity to
> > > happen in the driver core.  Do you think this is not a real bug?
> > 
> > Grr..  Typo on my part.  Patch 4 is the one I originally meant:
> > "Driver Core: Clarify device cleanup." It changes nothing but
> > comments.  I don't think it's a big deal at all, but are documentation
> > changes also allowed now?
> 
> It was a documentation change, fixing the information for a core API
> call to be correct and match what the code really does.
> 
> It also carried no risk of a regression, and as such, I decided to take
> it.  If you note, we have also taken other patches that fix up
> documentation issues like this in the past, so it was not the first
> time.
> 
> Was this that big of a deal?

No.  I said that already.  I'm just trying to clarify what the
expectations are for -stable because when it first started stuff liek
that wasn't taken.  Also, it seems nobody has updated the documentation
file as -stable has evolved.  I'd be more than happy to correct that,
but I just need to get a feel for where -stable is at before I can do
that.

Not trying to be a stick in the mud, just trying to help.  If you'd
rather I don't, that's fine too.

josh

Re: [stable] [patch 00/17] 2.6.27-stable review

[Greg KH]

On Thu, Oct 23, 2008 at 11:47:34AM -0400, Josh Boyer wrote:
> 
> No.  I said that already.  I'm just trying to clarify what the
> expectations are for -stable because when it first started stuff liek
> that wasn't taken.  Also, it seems nobody has updated the documentation
> file as -stable has evolved.  I'd be more than happy to correct that,
> but I just need to get a feel for where -stable is at before I can do
> that.

Adding the "we accept new device ids and quirks" would be good to have
added to the file, I have no problem with that.

thanks,

greg k-h

Re: [patch 00/17] 2.6.27-stable review

[Willy Tarreau]

On Wed, Oct 22, 2008 at 09:01:26PM -0400, Josh Boyer wrote:
> On Sat, Oct 18, 2008 at 11:33:34AM -0700, Greg KH wrote:
> >This is the start of the stable review cycle for the 2.6.27.3 release.
> >There are 17 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.
> >
> >These patches are sent out with a number of different people on the
> >Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
> >to add your name to the list.  If you want to be off the reviewer list,
> >also email us.
> >
> >Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
> >Anything received after that time might be too late.
> 
> OK, I realize I'm late.  Apologies in advance for that.
> 
> I don't see how patches 3, 16, and 17 really fit into the "stable"
> rules.  None of them:
> 
> "... fix a problem that causes a build error (but not for things
>  marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
>  security issue, or some "oh, that's not good" issue.  In short,
>  something critical."
> 
> So, are we being a bit more lax on the requirements for the
> -stable kernels and I missed the memo, or?

3 definitely is "oh that's not good", and 16&17 are just support
for a few new IDs. It's not the first time this happens, and as
long as there are not too many or they don't change the driver's
code, I don't see the problem. It increases the ability for people
to test the kernel and report bugs too BTW.

I think it's better to have strict rules and be lax sometimes
than having no rules at all or being too strict and annoy users.

Willy