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 [email protected]
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
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Cornelia Huck <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Oleg Nesterov <[email protected]>
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 <[email protected]>
Cc: Krzysztof Helt <[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/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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Cornelia Huck <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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)
{
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Chris Webb <[email protected]>
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 <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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) {
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Johannes Berg <[email protected]>
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 <[email protected]>
Acked-by: Luis R. Rodriguez <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Alexey Dobriyan <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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,
¬es_attrs->attrs[i]);
- kobject_del(notes_attrs->dir);
+ kobject_put(notes_attrs->dir);
}
kfree(notes_attrs);
}
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Christoph Hellwig <[email protected]>
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 <[email protected]>
Acked-by: Eric Sandeen <[email protected]>
Signed-off-by: Timothy Shimmin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
}
}
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Alan Stern <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Luis R. Rodriguez <[email protected]>
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 <[email protected]>
Signed-off-by: Vasanthakumar Thiagarajan <[email protected]>
Signed-off-by: Sujith <[email protected]>
Signed-off-by: Luis R. Rodriguez <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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,
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Yauhen Kharuzhy <[email protected]>
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 <[email protected]>
Signed-off-by: David Brownell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David Brownell <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Matthias Hopf <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Alan Stern <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Alan Stern <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David Brownell <[email protected]>
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 <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
*/
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Michael Krufky <[email protected]>
(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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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),
--
2.6.27-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Michael Krufky <[email protected]>
(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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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),
--
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(-)
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 [email protected]
>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
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 [email protected]
> >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
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 [email protected]
> >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
On Wed, 22 Oct 2008 21:53:45 -0700
Greg KH <[email protected]> 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 [email protected]
> > >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
On Thu, Oct 23, 2008 at 06:33:39AM -0400, Josh Boyer wrote:
> On Wed, 22 Oct 2008 21:53:45 -0700
> Greg KH <[email protected]> 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 [email protected]
> > > >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
On Thu, 23 Oct 2008 08:33:48 -0700
Greg KH <[email protected]> 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 <[email protected]> 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 [email protected]
> > > > >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
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