--- /dev/null
+From stable-bounces@linux.kernel.org Fri Aug 15 09:30:13 2008
+From: Carlos Corbacho <carlos@strangeworlds.co.uk>
+Date: Fri, 15 Aug 2008 16:30:03 GMT
+Subject: acer-wmi: Fix wireless and bluetooth on early AMW0 v2 laptops
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808151630.m7FGU3IW011006@hera.kernel.org>
+
+From: Carlos Corbacho <carlos@strangeworlds.co.uk>
+
+commit 5c742b45dd5fbbb6cf74d3378341704f4b23c5e8 upstream
+
+In the old acer_acpi, I discovered that on some of the newer AMW0 laptops
+that supported the WMID methods, they don't work properly for setting the
+wireless and bluetooth values.
+
+So for the AMW0 V2 laptops, we want to use both the 'old' AMW0 and the
+'new' WMID methods for setting wireless & bluetooth to guarantee we always
+enable it.
+
+This was fixed in acer_acpi some time ago, but I forgot to port the patch
+over to acer-wmi when it was merged.
+
+(Without this patch, early AMW0 V2 laptops such as the Aspire 5040 won't
+work with acer-wmi, where-as they did with the old acer_acpi).
+
+AK: fix compilation
+
+Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
+Signed-off-by: Andi Kleen <ak@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/misc/acer-wmi.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/drivers/misc/acer-wmi.c
++++ b/drivers/misc/acer-wmi.c
+@@ -742,11 +742,30 @@ static acpi_status get_u32(u32 *value, u
+
+ static acpi_status set_u32(u32 value, u32 cap)
+ {
++ acpi_status status;
++
+ if (interface->capability & cap) {
+ switch (interface->type) {
+ case ACER_AMW0:
+ return AMW0_set_u32(value, cap, interface);
+ case ACER_AMW0_V2:
++ if (cap == ACER_CAP_MAILLED)
++ return AMW0_set_u32(value, cap, interface);
++
++ /*
++ * On some models, some WMID methods don't toggle
++ * properly. For those cases, we want to run the AMW0
++ * method afterwards to be certain we've really toggled
++ * the device state.
++ */
++ if (cap == ACER_CAP_WIRELESS ||
++ cap == ACER_CAP_BLUETOOTH) {
++ status = WMID_set_u32(value, cap, interface);
++ if (ACPI_FAILURE(status))
++ return status;
++
++ return AMW0_set_u32(value, cap, interface);
++ }
+ case ACER_WMID:
+ return WMID_set_u32(value, cap, interface);
+ default:
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Aug 15 12:05:14 2008
+From: Steve French <sfrench@us.ibm.com>
+Date: Fri, 15 Aug 2008 19:05:06 GMT
+Subject: CIFS: if get root inode fails during mount, cleanup tree connection
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808151905.m7FJ56sc001284@hera.kernel.org>
+
+From: Steve French <sfrench@us.ibm.com>
+
+commit 2c731afb0d4ba16018b400c75665fbdb8feb2175 upstream
+
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/cifs/cifsfs.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/cifs/cifsfs.c
++++ b/fs/cifs/cifsfs.c
+@@ -175,6 +175,8 @@ out_no_root:
+ if (inode)
+ iput(inode);
+
++ cifs_umount(sb, cifs_sb);
++
+ out_mount_failed:
+ if (cifs_sb) {
+ #ifdef CONFIG_CIFS_DFS_UPCALL
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Aug 15 12:05:14 2008
+From: Steve French <sfrench@us.ibm.com>
+Date: Fri, 15 Aug 2008 19:05:03 GMT
+Subject: CIFS: mount of IPC$ breaks with iget patch
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808151905.m7FJ532E001099@hera.kernel.org>
+
+From: Steve French <sfrench@us.ibm.com>
+
+commit ad661334b8ae421154b121ee6ad3b56807adbf11 upstream
+
+In looking at network named pipe support on cifs, I noticed that
+Dave Howell's iget patch:
+
+ iget: stop CIFS from using iget() and read_inode()
+
+broke mounts to IPC$ (the interprocess communication share), and don't
+handle the error case (when getting info on the root inode fails).
+
+Thanks to Gunter who noted a typo in a debug line in the original
+version of this patch.
+
+CC: David Howells <dhowells@redhat.com>
+CC: Gunter Kukkukk <linux@kukkukk.com>
+Signed-off-by: Steve French <sfrench@us.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/cifs/inode.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/cifs/inode.c
++++ b/fs/cifs/inode.c
+@@ -649,6 +649,7 @@ struct inode *cifs_iget(struct super_blo
+ inode->i_fop = &simple_dir_operations;
+ inode->i_uid = cifs_sb->mnt_uid;
+ inode->i_gid = cifs_sb->mnt_gid;
++ } else if (rc) {
+ _FreeXid(xid);
+ iget_failed(inode);
+ return ERR_PTR(rc);
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 5 17:05:16 2008
+From: Petr Tesarik <ptesarik@suse.cz>
+Date: Wed, 6 Aug 2008 00:05:07 GMT
+Subject: ide-cd: fix endianity for the error message in cdrom_read_capacity
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808060005.m7605752008124@hera.kernel.org>
+
+From: Petr Tesarik <ptesarik@suse.cz>
+
+commit 938bb03d188a1e688fb0bcae49788f540193e80a uptream
+
+Aesthetic regards aside, commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667
+still leaves a bug in the error message, because it uses the unconverted
+big-endian value for printk.
+
+Fix this by using a local variable in machine byte order. The result is
+correct, more readable, and also produces slightly shorter code on i386.
+
+Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
+Cc: Jens Axboe <jens.axboe@oracle.com>
+Cc: Jan Kara <jack@suse.cz>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: <stable@kernel.org>
+Acked-by: Borislav Petkov <petkovbb@gmail.com>
+[bart: __u32 -> u32]
+Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ide/ide-cd.c | 18 ++++++++++--------
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+--- a/drivers/ide/ide-cd.c
++++ b/drivers/ide/ide-cd.c
+@@ -1298,6 +1298,7 @@ static int cdrom_read_capacity(ide_drive
+
+ int stat;
+ struct request req;
++ u32 blocklen;
+
+ ide_cd_init_rq(drive, &req);
+
+@@ -1314,23 +1315,24 @@ static int cdrom_read_capacity(ide_drive
+ /*
+ * Sanity check the given block size
+ */
+- switch (capbuf.blocklen) {
+- case __constant_cpu_to_be32(512):
+- case __constant_cpu_to_be32(1024):
+- case __constant_cpu_to_be32(2048):
+- case __constant_cpu_to_be32(4096):
++ blocklen = be32_to_cpu(capbuf.blocklen);
++ switch (blocklen) {
++ case 512:
++ case 1024:
++ case 2048:
++ case 4096:
+ break;
+ default:
+ printk(KERN_ERR "%s: weird block size %u\n",
+- drive->name, capbuf.blocklen);
++ drive->name, blocklen);
+ printk(KERN_ERR "%s: default to 2kb block size\n",
+ drive->name);
+- capbuf.blocklen = __constant_cpu_to_be32(2048);
++ blocklen = 2048;
+ break;
+ }
+
+ *capacity = 1 + be32_to_cpu(capbuf.lba);
+- *sectors_per_frame = be32_to_cpu(capbuf.blocklen) >> SECTOR_BITS;
++ *sectors_per_frame = blocklen >> SECTOR_BITS;
+ return 0;
+ }
+
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:31 2008
+From: Sven Wegener <sven.wegener@stealer.net>
+Date: Thu, 14 Aug 2008 03:55:22 GMT
+Subject: ipvs: Fix possible deadlock in estimator code
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3tMD6011966@hera.kernel.org>
+
+From: Sven Wegener <sven.wegener@stealer.net>
+
+commit 8ab19ea36c5c5340ff598e4d15fc084eb65671dc upstream
+
+There is a slight chance for a deadlock in the estimator code. We can't call
+del_timer_sync() while holding our lock, as the timer might be active and
+spinning for the lock on another cpu. Work around this issue by using
+try_to_del_timer_sync() and releasing the lock. We could actually delete the
+timer outside of our lock, as the add and kill functions are only every called
+from userspace via [gs]etsockopt() and are serialized by a mutex, but better
+make this explicit.
+
+Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
+Acked-by: Simon Horman <horms@verge.net.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/ipv4/ipvs/ip_vs_est.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/net/ipv4/ipvs/ip_vs_est.c
++++ b/net/ipv4/ipvs/ip_vs_est.c
+@@ -172,8 +172,11 @@ void ip_vs_kill_estimator(struct ip_vs_s
+ kfree(est);
+ killed++;
+ }
+- if (killed && est_list == NULL)
+- del_timer_sync(&est_timer);
++ while (killed && !est_list && try_to_del_timer_sync(&est_timer) < 0) {
++ write_unlock_bh(&est_lock);
++ cpu_relax();
++ write_lock_bh(&est_lock);
++ }
+ write_unlock_bh(&est_lock);
+ }
+
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 12 16:20:17 2008
+From: Jean Delvare <khali@linux-fr.org>
+Date: Tue, 12 Aug 2008 23:20:04 GMT
+Subject: matrox maven: fix a broken error path
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808122320.m7CNK4JU029404@hera.kernel.org>
+
+From: Jean Delvare <khali@linux-fr.org>
+
+commit 5ede40f87957c6ededf9284c8339722a97b9dfb6 upstream
+
+I broke an error path with d03c21ec0be7787ff6b75dcf56c0e96209ccbfbd,
+sorry about that.
+
+The machine will crash if the i2c_attach_client() or maven_init_client()
+calls fail, although nobody has yet reported this happening.
+
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
+Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
+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/matrox/matroxfb_maven.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/matrox/matroxfb_maven.c
++++ b/drivers/video/matrox/matroxfb_maven.c
+@@ -1266,7 +1266,7 @@ static int maven_detect_client(struct i2
+ ERROR4:;
+ i2c_detach_client(new_client);
+ ERROR3:;
+- kfree(new_client);
++ kfree(data);
+ ERROR0:;
+ return err;
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Mon Aug 4 17:20:12 2008
+From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+Date: Tue, 5 Aug 2008 00:20:05 GMT
+Subject: mlock() fix return values
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808050020.m750K5FW020170@hera.kernel.org>
+
+From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+
+commit a477097d9c37c1cf289c7f0257dffcfa42d50197 upstream
+
+Halesh says:
+
+Please find the below testcase provide to test mlock.
+
+Test Case :
+===========================
+
+#include <sys/resource.h>
+#include <stdio.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <sys/mman.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <stdlib.h>
+
+int main(void)
+{
+ int fd,ret, i = 0;
+ char *addr, *addr1 = NULL;
+ unsigned int page_size;
+ struct rlimit rlim;
+
+ if (0 != geteuid())
+ {
+ printf("Execute this pgm as root\n");
+ exit(1);
+ }
+
+ /* create a file */
+ if ((fd = open("mmap_test.c",O_RDWR|O_CREAT,0755)) == -1)
+ {
+ printf("cant create test file\n");
+ exit(1);
+ }
+
+ page_size = sysconf(_SC_PAGE_SIZE);
+
+ /* set the MEMLOCK limit */
+ rlim.rlim_cur = 2000;
+ rlim.rlim_max = 2000;
+
+ if ((ret = setrlimit(RLIMIT_MEMLOCK,&rlim)) != 0)
+ {
+ printf("Cant change limit values\n");
+ exit(1);
+ }
+
+ addr = 0;
+ while (1)
+ {
+ /* map a page into memory each time*/
+ if ((addr = (char *) mmap(addr,page_size, PROT_READ |
+PROT_WRITE,MAP_SHARED,fd,0)) == MAP_FAILED)
+ {
+ printf("cant do mmap on file\n");
+ exit(1);
+ }
+
+ if (0 == i)
+ addr1 = addr;
+ i++;
+ errno = 0;
+ /* lock the mapped memory pagewise*/
+ if ((ret = mlock((char *)addr, 1500)) == -1)
+ {
+ printf("errno value is %d\n", errno);
+ printf("cant lock maped region\n");
+ exit(1);
+ }
+ addr = addr + page_size;
+ }
+}
+======================================================
+
+This testcase results in an mlock() failure with errno 14 that is EFAULT,
+but it has nowhere been specified that mlock() will return EFAULT. When I
+tested the same on older kernels like 2.6.18, I got the correct result i.e
+errno 12 (ENOMEM).
+
+I think in source code mlock(2), setting errno ENOMEM has been missed in
+do_mlock() , on mlock_fixup() failure.
+
+SUSv3 requires the following behavior frmo mlock(2).
+
+[ENOMEM]
+ Some or all of the address range specified by the addr and
+ len arguments does not correspond to valid mapped pages
+ in the address space of the process.
+
+[EAGAIN]
+ Some or all of the memory identified by the operation could not
+ be locked when the call was made.
+
+This rule isn't so nice and slighly strange. but many people think
+POSIX/SUS compliance is important.
+
+Reported-by: Halesh Sadashiv <halesh.sadashiv@ap.sony.com>
+Tested-by: Halesh Sadashiv <halesh.sadashiv@ap.sony.com>
+Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
+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>
+
+---
+ mm/memory.c | 16 +++++++++++++---
+ mm/mlock.c | 2 --
+ 2 files changed, 13 insertions(+), 5 deletions(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -2748,16 +2748,26 @@ int make_pages_present(unsigned long add
+
+ vma = find_vma(current->mm, addr);
+ if (!vma)
+- return -1;
++ return -ENOMEM;
+ write = (vma->vm_flags & VM_WRITE) != 0;
+ BUG_ON(addr >= end);
+ BUG_ON(end > vma->vm_end);
+ len = DIV_ROUND_UP(end, PAGE_SIZE) - addr/PAGE_SIZE;
+ ret = get_user_pages(current, current->mm, addr,
+ len, write, 0, NULL, NULL);
+- if (ret < 0)
++ if (ret < 0) {
++ /*
++ SUS require strange return value to mlock
++ - invalid addr generate to ENOMEM.
++ - out of memory should generate EAGAIN.
++ */
++ if (ret == -EFAULT)
++ ret = -ENOMEM;
++ else if (ret == -ENOMEM)
++ ret = -EAGAIN;
+ return ret;
+- return ret == len ? 0 : -1;
++ }
++ return ret == len ? 0 : -ENOMEM;
+ }
+
+ #if !defined(__HAVE_ARCH_GATE_AREA)
+--- a/mm/mlock.c
++++ b/mm/mlock.c
+@@ -78,8 +78,6 @@ success:
+
+ mm->locked_vm -= pages;
+ out:
+- if (ret == -ENOMEM)
+- ret = -EAGAIN;
+ return ret;
+ }
+
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 12 08:30:25 2008
+From: Oleg Nesterov <oleg@tv-sign.ru>
+Date: Tue, 12 Aug 2008 15:30:09 GMT
+Subject: posix-timers: do_schedule_next_timer: fix the setting of ->si_overrun
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808121530.m7CFU9K7013752@hera.kernel.org>
+
+From: Oleg Nesterov <oleg@tv-sign.ru>
+
+commit 54da1174922cddd4be83d5a364b2e0fdd693f513 upstream
+
+do_schedule_next_timer() sets info->si_overrun = timr->it_overrun_last,
+this discards the already accumulated overruns.
+
+Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
+Cc: Mark McLoughlin <markmc@redhat.com>
+Cc: Oliver Pinter <oliver.pntr@gmail.com>
+Cc: Roland McGrath <roland@redhat.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/posix-timers.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/posix-timers.c
++++ b/kernel/posix-timers.c
+@@ -289,7 +289,7 @@ void do_schedule_next_timer(struct sigin
+ else
+ schedule_next_timer(timr);
+
+- info->si_overrun = timr->it_overrun_last;
++ info->si_overrun += timr->it_overrun_last;
+ }
+
+ if (timr)
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 12 08:30:25 2008
+From: Oleg Nesterov <oleg@tv-sign.ru>
+Date: Tue, 12 Aug 2008 15:30:06 GMT
+Subject: posix-timers: fix posix_timer_event() vs dequeue_signal() race
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808121530.m7CFU6Di013669@hera.kernel.org>
+
+From: Oleg Nesterov <oleg@tv-sign.ru>
+
+commit ba661292a2bc6ddd305a212b0526e5dc22195fe7 upstream
+
+The bug was reported and analysed by Mark McLoughlin <markmc@redhat.com>,
+the patch is based on his and Roland's suggestions.
+
+posix_timer_event() always rewrites the pre-allocated siginfo before sending
+the signal. Most of the written info is the same all the time, but memset(0)
+is very wrong. If ->sigq is queued we can race with collect_signal() which
+can fail to find this siginfo looking at .si_signo, or copy_siginfo() can
+copy the wrong .si_code/si_tid/etc.
+
+In short, sys_timer_settime() can in fact stop the active timer, or the user
+can receive the siginfo with the wrong .si_xxx values.
+
+Move "memset(->info, 0)" from posix_timer_event() to alloc_posix_timer(),
+change send_sigqueue() to set .si_overrun = 0 when ->sigq is not queued.
+It would be nice to move the whole sigq->info initialization from send to
+create path, but this is not easy to do without uglifying timer_create()
+further.
+
+As Roland rightly pointed out, we need more cleanups/fixes here, see the
+"FIXME" comment in the patch. Hopefully this patch makes sense anyway, and
+it can mask the most bad implications.
+
+Reported-by: Mark McLoughlin <markmc@redhat.com>
+Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
+Cc: Mark McLoughlin <markmc@redhat.com>
+Cc: Oliver Pinter <oliver.pntr@gmail.com>
+Cc: Roland McGrath <roland@redhat.com>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/posix-timers.c | 17 +++++++++++++----
+ kernel/signal.c | 1 +
+ 2 files changed, 14 insertions(+), 4 deletions(-)
+
+--- a/kernel/posix-timers.c
++++ b/kernel/posix-timers.c
+@@ -296,14 +296,22 @@ void do_schedule_next_timer(struct sigin
+ unlock_timer(timr, flags);
+ }
+
+-int posix_timer_event(struct k_itimer *timr,int si_private)
++int posix_timer_event(struct k_itimer *timr, int si_private)
+ {
+- memset(&timr->sigq->info, 0, sizeof(siginfo_t));
++ /*
++ * FIXME: if ->sigq is queued we can race with
++ * dequeue_signal()->do_schedule_next_timer().
++ *
++ * If dequeue_signal() sees the "right" value of
++ * si_sys_private it calls do_schedule_next_timer().
++ * We re-queue ->sigq and drop ->it_lock().
++ * do_schedule_next_timer() locks the timer
++ * and re-schedules it while ->sigq is pending.
++ * Not really bad, but not that we want.
++ */
+ timr->sigq->info.si_sys_private = si_private;
+- /* Send signal to the process that owns this timer.*/
+
+ timr->sigq->info.si_signo = timr->it_sigev_signo;
+- timr->sigq->info.si_errno = 0;
+ timr->sigq->info.si_code = SI_TIMER;
+ timr->sigq->info.si_tid = timr->it_id;
+ timr->sigq->info.si_value = timr->it_sigev_value;
+@@ -435,6 +443,7 @@ static struct k_itimer * alloc_posix_tim
+ kmem_cache_free(posix_timers_cache, tmr);
+ tmr = NULL;
+ }
++ memset(&tmr->sigq->info, 0, sizeof(siginfo_t));
+ return tmr;
+ }
+
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -1319,6 +1319,7 @@ int send_sigqueue(struct sigqueue *q, st
+ q->info.si_overrun++;
+ goto out;
+ }
++ q->info.si_overrun = 0;
+
+ signalfd_notify(t, sig);
+ pending = group ? &t->signal->shared_pending : &t->pending;
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 12 16:20:17 2008
+From: David Miller <davem@davemloft.net>
+Date: Tue, 12 Aug 2008 23:20:06 GMT
+Subject: radeonfb: fix accel engine hangs
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808122320.m7CNK6Rl029438@hera.kernel.org>
+
+From: David Miller <davem@davemloft.net>
+
+commit 969830b2fedf8336c41d6195f49d250b1e166ff8 upstream
+
+Some chips appear to have the 2D engine hang during screen redraw,
+typically in a sequence of copyarea operations. This appear to be
+solved by adding a flush of the engine destination pixel cache
+and waiting for the engine to be idle before issuing the accel
+operation. The performance impact seems to be fairly small.
+
+Here is a trace on an RV370 (PCI device ID 0x5b64), it records the
+RBBM_STATUS register, then the source x/y, destination x/y, and
+width/height used for the copy:
+
+----------------------------------------
+radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]
+radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]
+radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]
+radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]
+radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]
+radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]
+radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]
+radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]
+radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]
+radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]
+radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]
+----------------------------------------
+
+When things are going fine the copies complete before the next ROP is
+even issued, but all of a sudden the 2D unit becomes active (bit 17 in
+RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit
+14) are set as well. The FIFO begins to backup until it becomes full.
+
+What happens next is the radeon_fifo_wait() times out, and we access
+the chip illegally leading to a bus error which usually wedges the
+box. None of this makes it to the console screen, of course :-)
+radeon_fifo_wait() should be modified to reset the accelerator when
+this timeout happens instead of programming the chip anyways.
+
+----------------------------------------
+radeonfb: FIFO Timeout !
+ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)
+ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]
+ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248>
+ERROR(0): M_SYND(0), E_SYND(0), Privileged
+ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus"
+ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
+ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
+ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\
+
+ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
+ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
+ERROR(0): E-cache idx[800e40] tag[000000000e049f4c]
+ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]
+Ker:xnel panic - not syncing: Irrecoverable deferred error trap.
+----------------------------------------
+
+Another quirk is that these copyarea calls will not happen until the
+first drivers/char/vt.c:redraw_screen() occurs. This will only happen
+if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen.
+
+This seems to happen because until a redraw_screen() the screen scrolling
+method used by fbcon is not finalized yet. I've seen this with other fb
+drivers too.
+
+So if all you do is boot straight into X you will never see this bug on
+the relevant chips.
+
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+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/aty/radeon_accel.c | 8 ++++++++
+ include/video/radeon.h | 4 ++++
+ 2 files changed, 12 insertions(+)
+
+--- a/drivers/video/aty/radeon_accel.c
++++ b/drivers/video/aty/radeon_accel.c
+@@ -55,6 +55,10 @@ static void radeonfb_prim_fillrect(struc
+ OUTREG(DP_WRITE_MSK, 0xffffffff);
+ OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM));
+
++ radeon_fifo_wait(2);
++ OUTREG(DSTCACHE_CTLSTAT, RB2D_DC_FLUSH_ALL);
++ OUTREG(WAIT_UNTIL, (WAIT_2D_IDLECLEAN | WAIT_DMA_GUI_IDLE));
++
+ radeon_fifo_wait(2);
+ OUTREG(DST_Y_X, (region->dy << 16) | region->dx);
+ OUTREG(DST_WIDTH_HEIGHT, (region->width << 16) | region->height);
+@@ -116,6 +120,10 @@ static void radeonfb_prim_copyarea(struc
+ OUTREG(DP_CNTL, (xdir>=0 ? DST_X_LEFT_TO_RIGHT : 0)
+ | (ydir>=0 ? DST_Y_TOP_TO_BOTTOM : 0));
+
++ radeon_fifo_wait(2);
++ OUTREG(DSTCACHE_CTLSTAT, RB2D_DC_FLUSH_ALL);
++ OUTREG(WAIT_UNTIL, (WAIT_2D_IDLECLEAN | WAIT_DMA_GUI_IDLE));
++
+ radeon_fifo_wait(3);
+ OUTREG(SRC_Y_X, (sy << 16) | sx);
+ OUTREG(DST_Y_X, (dy << 16) | dx);
+--- a/include/video/radeon.h
++++ b/include/video/radeon.h
+@@ -741,6 +741,10 @@
+ #define SOFT_RESET_RB (1 << 6)
+ #define SOFT_RESET_HDP (1 << 7)
+
++/* WAIT_UNTIL bit constants */
++#define WAIT_DMA_GUI_IDLE (1 << 9)
++#define WAIT_2D_IDLECLEAN (1 << 16)
++
+ /* SURFACE_CNTL bit consants */
+ #define SURF_TRANSLATION_DIS (1 << 8)
+ #define NONSURF_AP0_SWP_16BPP (1 << 20)
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 5 17:05:12 2008
+From: Tom Zanussi <tzanussi@gmail.com>
+Date: Wed, 6 Aug 2008 00:05:03 GMT
+Subject: relay: fix "full buffer with exactly full last subbuffer" accounting problem
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808060005.m76053aV008044@hera.kernel.org>
+
+From: Tom Zanussi <tzanussi@gmail.com>
+
+commit 32194450330be327f3b25bf6b66298bd122599e9 upstream
+
+In relay's current read implementation, if the buffer is completely full
+but hasn't triggered the buffer-full condition (i.e. the last write
+didn't cross the subbuffer boundary) and the last subbuffer is exactly
+full, the subbuffer accounting code erroneously finds nothing available.
+This patch fixes the problem.
+
+Signed-off-by: Tom Zanussi <tzanussi@gmail.com>
+Cc: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
+Cc: Pekka Enberg <penberg@cs.helsinki.fi>
+Cc: Jens Axboe <jens.axboe@oracle.com>
+Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
+Cc: Andrea Righi <righi.andrea@gmail.com>
+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>
+
+---
+ kernel/relay.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/kernel/relay.c
++++ b/kernel/relay.c
+@@ -832,6 +832,10 @@ static void relay_file_read_consume(stru
+ size_t n_subbufs = buf->chan->n_subbufs;
+ size_t read_subbuf;
+
++ if (buf->subbufs_produced == buf->subbufs_consumed &&
++ buf->offset == buf->bytes_consumed)
++ return;
++
+ if (buf->bytes_consumed + bytes_consumed > subbuf_size) {
+ relay_subbufs_consumed(buf->chan, buf->cpu, 1);
+ buf->bytes_consumed = 0;
+@@ -863,6 +867,8 @@ static int relay_file_read_avail(struct
+
+ relay_file_read_consume(buf, read_pos, 0);
+
++ consumed = buf->subbufs_consumed;
++
+ if (unlikely(buf->offset > subbuf_size)) {
+ if (produced == consumed)
+ return 0;
+@@ -881,8 +887,12 @@ static int relay_file_read_avail(struct
+ if (consumed > produced)
+ produced += n_subbufs * subbuf_size;
+
+- if (consumed == produced)
++ if (consumed == produced) {
++ if (buf->offset == subbuf_size &&
++ buf->subbufs_produced > buf->subbufs_consumed)
++ return 1;
+ return 0;
++ }
+
+ return 1;
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Mon Aug 4 17:30:13 2008
+From: Tim Wright <timw@splhi.com>
+Date: Tue, 5 Aug 2008 00:30:07 GMT
+Subject: SCSI: block: Fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler.
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808050030.m750U75s022296@hera.kernel.org>
+
+From: Tim Wright <timw@splhi.com>
+
+commit ad337591f4fd20de6a0ca03d6715267a5c1d2b16 upstream
+
+It seems cdrwtool in the udftools has been unusable on "modern" kernels
+for some time. A Google search reveals many people with the same issue
+but no solution (cdrwtool fails to format the disk). After spending some
+time tracking down the issue, it comes down to the following:
+
+The udftools still use the older CDROM_SEND_PACKET interface to send
+things like FORMAT_UNIT through to the drive. They should really be
+updated, but that's another story. Since most distros are using libata
+now, the cd or dvd burner appears as a SCSI device, and we wind up in
+block/scsi_ioctl.c. Here, the code tries to take the "struct
+cdrom_generic_command" and translate it and stuff it into a "struct
+sg_io_hdr" structure so it can pass it to the modern sg_io() routine
+instead. Unfortunately, there is one error, or rather an omission in the
+translation. The timeout that is passed in in the "struct
+cdrom_generic_command" is in HZ=100 units, and this is modified and
+correctly converted to jiffies by use of clock_t_to_jiffies(). However,
+a little further down, this cgc.timeout value in jiffies is simply
+copied into the sg_io_hdr timeout, which should be in milliseconds.
+Since most modern x86 kernels seems to be getting build with HZ=250, the
+timeout that is passed to sg_io and eventually converted to the
+timeout_per_command member of the scsi_cmnd structure is now four times
+too small. Since cdrwtool tries to set the timeout to one hour for the
+FORMAT_UNIT command, and it takes about 20 minutes to format a 4x CDRW,
+the SCSI error-handler kicks in after the FORMAT_UNIT completes because
+it took longer than the incorrectly-calculated timeout.
+
+[jejb: fix up whitespace]
+Signed-off-by: Tim Wright <timw@splhi.com>
+Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ block/scsi_ioctl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/block/scsi_ioctl.c
++++ b/block/scsi_ioctl.c
+@@ -629,7 +629,7 @@ int scsi_cmd_ioctl(struct file *file, st
+ hdr.sbp = cgc.sense;
+ if (hdr.sbp)
+ hdr.mx_sb_len = sizeof(struct request_sense);
+- hdr.timeout = cgc.timeout;
++ hdr.timeout = jiffies_to_msecs(cgc.timeout);
+ hdr.cmdp = ((struct cdrom_generic_command __user*) arg)->cmd;
+ hdr.cmd_len = sizeof(cgc.cmd);
+
--- /dev/null
+From stable-bounces@linux.kernel.org Mon Aug 4 17:30:17 2008
+From: HighPoint Linux Team <linux@highpoint-tech.com>
+Date: Tue, 5 Aug 2008 00:30:10 GMT
+Subject: SCSI: hptiop: add more PCI device IDs
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808050030.m750UAI3022319@hera.kernel.org>
+
+From: HighPoint Linux Team <linux@highpoint-tech.com>
+
+commit dd07428b44944b42f699408fe31af47977f1e733 upstream
+
+Add PCI device ID for new adapter models.
+
+Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com>
+Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/scsi/hptiop.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/scsi/hptiop.c
++++ b/drivers/scsi/hptiop.c
+@@ -1249,6 +1249,13 @@ static struct pci_device_id hptiop_id_ta
+ { PCI_VDEVICE(TTI, 0x3522), (kernel_ulong_t)&hptiop_itl_ops },
+ { PCI_VDEVICE(TTI, 0x3410), (kernel_ulong_t)&hptiop_itl_ops },
+ { PCI_VDEVICE(TTI, 0x3540), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x3530), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x3560), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x4322), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x4210), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x4211), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x4310), (kernel_ulong_t)&hptiop_itl_ops },
++ { PCI_VDEVICE(TTI, 0x4311), (kernel_ulong_t)&hptiop_itl_ops },
+ { PCI_VDEVICE(TTI, 0x3120), (kernel_ulong_t)&hptiop_mv_ops },
+ { PCI_VDEVICE(TTI, 0x3122), (kernel_ulong_t)&hptiop_mv_ops },
+ { PCI_VDEVICE(TTI, 0x3020), (kernel_ulong_t)&hptiop_mv_ops },
--- /dev/null
+From stable-bounces@linux.kernel.org Mon Aug 4 17:30:13 2008
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+Date: Tue, 5 Aug 2008 00:30:02 GMT
+Subject: SCSI: scsi_transport_spi: fix oops in revalidate
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808050030.m750U2KD022006@hera.kernel.org>
+
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+
+commit e8bac9e0647dd04c83fd0bfe7cdfe2f6dfb100d0 upstream
+
+The class_device->device conversion is causing an oops in revalidate
+because it's assuming that the device_for_each_child iterator will only
+return struct scsi_device children. The conversion made all former
+class_devices children of the device as well, so this assumption is
+broken. Fix it.
+
+Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/scsi/scsi_transport_spi.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/scsi/scsi_transport_spi.c
++++ b/drivers/scsi/scsi_transport_spi.c
+@@ -366,12 +366,14 @@ spi_transport_rd_attr(rti, "%d\n");
+ spi_transport_rd_attr(pcomp_en, "%d\n");
+ spi_transport_rd_attr(hold_mcs, "%d\n");
+
+-/* we only care about the first child device so we return 1 */
++/* we only care about the first child device that's a real SCSI device
++ * so we return 1 to terminate the iteration when we find it */
+ static int child_iter(struct device *dev, void *data)
+ {
+- struct scsi_device *sdev = to_scsi_device(dev);
++ if (!scsi_is_sdev_device(dev))
++ return 0;
+
+- spi_dv_device(sdev);
++ spi_dv_device(to_scsi_device(dev));
+ return 1;
+ }
+
--- /dev/null
+From stable-bounces@linux.kernel.org Mon Aug 4 17:30:13 2008
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+Date: Tue, 5 Aug 2008 00:30:05 GMT
+Subject: SCSI: ses: fix VPD inquiry overrun
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808050030.m750U5m4022204@hera.kernel.org>
+
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+
+commit 671a99c8eb2f1dde08ac5538d8cd912047c61ddf upstream
+
+There are a few kerneloops.org reports like this one:
+
+http://www.kerneloops.org/search.php?search=ses_match_to_enclosure
+
+That seem to imply we're running off the end of the VPD inquiry data
+(although at 512 bytes, it should be long enough for just about
+anything). we should be using correctly sized buffers anyway, so put
+those in and hope this oops goes away.
+
+Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/scsi/ses.c | 18 ++++++++++++++----
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -345,14 +345,14 @@ static int ses_enclosure_find_by_addr(st
+ return 0;
+ }
+
+-#define VPD_INQUIRY_SIZE 512
++#define VPD_INQUIRY_SIZE 36
+
+ static void ses_match_to_enclosure(struct enclosure_device *edev,
+ struct scsi_device *sdev)
+ {
+ unsigned char *buf = kmalloc(VPD_INQUIRY_SIZE, GFP_KERNEL);
+ unsigned char *desc;
+- int len;
++ u16 vpd_len;
+ struct efd efd = {
+ .addr = 0,
+ };
+@@ -372,9 +372,19 @@ static void ses_match_to_enclosure(struc
+ VPD_INQUIRY_SIZE, NULL, SES_TIMEOUT, SES_RETRIES))
+ goto free;
+
+- len = (buf[2] << 8) + buf[3];
++ vpd_len = (buf[2] << 8) + buf[3];
++ kfree(buf);
++ buf = kmalloc(vpd_len, GFP_KERNEL);
++ if (!buf)
++ return;
++ cmd[3] = vpd_len >> 8;
++ cmd[4] = vpd_len & 0xff;
++ if (scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buf,
++ vpd_len, NULL, SES_TIMEOUT, SES_RETRIES))
++ goto free;
++
+ desc = buf + 4;
+- while (desc < buf + len) {
++ while (desc < buf + vpd_len) {
+ enum scsi_protocol proto = desc[0] >> 4;
+ u8 code_set = desc[0] & 0x0f;
+ u8 piv = desc[1] & 0x80;
--- /dev/null
+mlock-fix-return-values.patch
+scsi-ses-fix-vpd-inquiry-overrun.patch
+scsi-scsi_transport_spi-fix-oops-in-revalidate.patch
+scsi-block-fix-miscalculation-of-sg_io-timeout-in-cdrom_send_packet-handler.patch
+scsi-hptiop-add-more-pci-device-ids.patch
+vt8623fb-fix-kernel-oops.patch
+relay-fix-full-buffer-with-exactly-full-last-subbuffer-accounting-problem.patch
+ide-cd-fix-endianity-for-the-error-message-in-cdrom_read_capacity.patch
+posix-timers-do_schedule_next_timer-fix-the-setting-of-si_overrun.patch
+posix-timers-fix-posix_timer_event-vs-dequeue_signal-race.patch
+radeonfb-fix-accel-engine-hangs.patch
+matrox-maven-fix-a-broken-error-path.patch
+usb-pl2023-remove-usb-id-handled-by-ch341.patch
+usb-fix-interface-unregistration-logic.patch
+usb-storage-unusual_devs-entries-for-iriver-t10-and-datafab-cf-sm-reader.patch
+usb-usb-storage-quirk-around-v1.11-firmware-on-nikon-d4.patch
+usb-serial-don-t-release-unregistered-minors.patch
+usb-ftdi_sio-add-support-for-luminance-stellaris-evaluation-development-kits.patch
+usb-ftdi_sio-add-usb-product-id-for-elv-hs485.patch
+ipvs-fix-possible-deadlock-in-estimator-code.patch
+acer-wmi-fix-wireless-and-bluetooth-on-early-amw0-v2-laptops.patch
+cifs-mount-of-ipc-breaks-with-iget-patch.patch
+cifs-if-get-root-inode-fails-during-mount-cleanup-tree-connection.patch
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:16 2008
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 14 Aug 2008 03:55:09 GMT
+Subject: USB: fix interface unregistration logic
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3t9RB011781@hera.kernel.org>
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 1a21175a615ed346e8043f5e9d60a672266b84b4 upstream
+
+
+This patch (as1122) fixes a bug: When an interface is unregistered,
+its children (sysfs files and endpoint devices) are unregistered after
+it instead of before.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Tested-by: Kay Sievers <kay.sievers@vrfy.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/core/message.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/core/message.c
++++ b/drivers/usb/core/message.c
+@@ -1091,8 +1091,8 @@ void usb_disable_device(struct usb_devic
+ continue;
+ dev_dbg(&dev->dev, "unregistering interface %s\n",
+ interface->dev.bus_id);
+- device_del(&interface->dev);
+ usb_remove_sysfs_intf_files(interface);
++ device_del(&interface->dev);
+ }
+
+ /* Now that the interfaces are unbound, nobody should
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:26 2008
+From: Frederik Kriewitz <frederik@kriewitz.eu>
+Date: Thu, 14 Aug 2008 03:55:16 GMT
+Subject: USB: ftdi_sio: add support for Luminance Stellaris Evaluation/Development Kits
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3tGa4011852@hera.kernel.org>
+
+From: Frederik Kriewitz <frederik@kriewitz.eu>
+
+commit a00c3cadc2bf50b3c925acdb3d0e5789b1650498 upstream
+
+The Patch adds support for Luminance Stellaris Evaluation/Development
+Kits (FTDI 2232C based).
+The PIDs were missing.
+
+Successfully tested with a Stellaris LM3S8962 Evaluation kit.
+
+Signed-off-by: Frederik Kriewitz <frederik@kriewitz.eu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/ftdi_sio.c | 4 ++++
+ drivers/usb/serial/ftdi_sio.h | 5 +++++
+ 2 files changed, 9 insertions(+)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -636,6 +636,10 @@ static struct usb_device_id id_table_com
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
+ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
++ { USB_DEVICE(FTDI_VID, LMI_LM3S_DEVEL_BOARD_PID),
++ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
++ { USB_DEVICE(FTDI_VID, LMI_LM3S_EVAL_BOARD_PID),
++ .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE(RATOC_VENDOR_ID, RATOC_PRODUCT_ID_USB60F) },
+ { USB_DEVICE(FTDI_VID, FTDI_REU_TINY_PID) },
+ { }, /* Optional parameter entry */
+--- a/drivers/usb/serial/ftdi_sio.h
++++ b/drivers/usb/serial/ftdi_sio.h
+@@ -815,6 +815,11 @@
+ #define OLIMEX_VID 0x15BA
+ #define OLIMEX_ARM_USB_OCD_PID 0x0003
+
++/* Luminary Micro Stellaris Boards, VID = FTDI_VID */
++/* FTDI 2332C Dual channel device, side A=245 FIFO (JTAG), Side B=RS232 UART */
++#define LMI_LM3S_DEVEL_BOARD_PID 0xbcd8
++#define LMI_LM3S_EVAL_BOARD_PID 0xbcd9
++
+ /* www.elsterelectricity.com Elster Unicom III Optical Probe */
+ #define FTDI_ELSTER_UNICOM_PID 0xE700 /* Product Id */
+
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:29 2008
+From: Andre Schenk <andre@melior.s.bawue.de>
+Date: Thu, 14 Aug 2008 03:55:19 GMT
+Subject: USB: ftdi_sio: Add USB Product Id for ELV HS485
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3tJ2o011876@hera.kernel.org>
+
+From: Andre Schenk <andre@melior.s.bawue.de>
+
+commit b5894a500127fce1db1309db5f9ca8b77a2ac266 upstream
+
+USB product id registration for the ELV HS485 USB adapter (www.elv.de) to
+their home automation bus system. Applies to 2.6.26.
+
+Signed-off-by: Andre Schenk <andre@melior.s.bawue.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/ftdi_sio.c | 1 +
+ drivers/usb/serial/ftdi_sio.h | 1 +
+ 2 files changed, 2 insertions(+)
+
+--- a/drivers/usb/serial/ftdi_sio.c
++++ b/drivers/usb/serial/ftdi_sio.c
+@@ -553,6 +553,7 @@ static struct usb_device_id id_table_com
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_FHZ1300PC_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_EM1010PC_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_ELV_WS500_PID) },
++ { USB_DEVICE(FTDI_VID, FTDI_ELV_HS485_PID) },
+ { USB_DEVICE(FTDI_VID, LINX_SDMUSBQSS_PID) },
+ { USB_DEVICE(FTDI_VID, LINX_MASTERDEVEL2_PID) },
+ { USB_DEVICE(FTDI_VID, LINX_FUTURE_0_PID) },
+--- a/drivers/usb/serial/ftdi_sio.h
++++ b/drivers/usb/serial/ftdi_sio.h
+@@ -524,6 +524,7 @@
+ #define FTDI_ELV_WS300PC_PID 0xE0F6 /* PC-Wetterstation (WS 300 PC) */
+ #define FTDI_ELV_FHZ1300PC_PID 0xE0E8 /* FHZ 1300 PC */
+ #define FTDI_ELV_WS500_PID 0xE0E9 /* PC-Wetterstation (WS 500) */
++#define FTDI_ELV_HS485_PID 0xE0EA /* USB to RS-485 adapter */
+ #define FTDI_ELV_EM1010PC_PID 0xE0EF /* Engery monitor EM 1010 PC */
+
+ /*
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:16 2008
+From: Tollef Fog Heen <tfheen@err.no>
+Date: Thu, 14 Aug 2008 03:55:05 GMT
+Subject: USB: pl2023: Remove USB id (4348:5523) handled by ch341
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3t5kI011738@hera.kernel.org>
+
+From: Tollef Fog Heen <tfheen@err.no>
+
+commit 8c809681ba0289afd0ed7bbb63679a0568dd441d upstream
+
+USB ID 4348:5523 is handled by the ch341 driver. Remove it from the
+pl2023 driver.
+
+Reverts 002e8f2c80c6be76bb312940bc278fc10b2b2487.
+
+Signed-off-by: Tollef Fog Heen <tfheen@err.no>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/pl2303.c | 1 -
+ drivers/usb/serial/pl2303.h | 4 ----
+ 2 files changed, 5 deletions(-)
+
+--- a/drivers/usb/serial/pl2303.c
++++ b/drivers/usb/serial/pl2303.c
+@@ -89,7 +89,6 @@ static struct usb_device_id id_table []
+ { USB_DEVICE(ALCOR_VENDOR_ID, ALCOR_PRODUCT_ID) },
+ { USB_DEVICE(WS002IN_VENDOR_ID, WS002IN_PRODUCT_ID) },
+ { USB_DEVICE(COREGA_VENDOR_ID, COREGA_PRODUCT_ID) },
+- { USB_DEVICE(HL340_VENDOR_ID, HL340_PRODUCT_ID) },
+ { USB_DEVICE(YCCABLE_VENDOR_ID, YCCABLE_PRODUCT_ID) },
+ { } /* Terminating entry */
+ };
+--- a/drivers/usb/serial/pl2303.h
++++ b/drivers/usb/serial/pl2303.h
+@@ -107,10 +107,6 @@
+ #define COREGA_VENDOR_ID 0x07aa
+ #define COREGA_PRODUCT_ID 0x002a
+
+-/* HL HL-340 (ID: 4348:5523) */
+-#define HL340_VENDOR_ID 0x4348
+-#define HL340_PRODUCT_ID 0x5523
+-
+ /* Y.C. Cable U.S.A., Inc - USB to RS-232 */
+ #define YCCABLE_VENDOR_ID 0x05ad
+ #define YCCABLE_PRODUCT_ID 0x0fba
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:21 2008
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 14 Aug 2008 03:55:11 GMT
+Subject: usb-serial: don't release unregistered minors
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3tBL0011803@hera.kernel.org>
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 0282b7f2a874e72c18fcd5a112ccf67f71ba7f5c upstream
+
+This patch (as1121) fixes a bug in the USB serial core. When a device
+is unregistered, the core will give back its minors -- even if the
+device hasn't been assigned any!
+
+The patch reserves the highest minor value (255) to mean that no minor
+was assigned. It also removes some dead code and does a small style
+fixup.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/serial/usb-serial.c | 7 +++----
+ include/linux/usb/serial.h | 3 ++-
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/serial/usb-serial.c
++++ b/drivers/usb/serial/usb-serial.c
+@@ -119,9 +119,6 @@ static void return_serial(struct usb_ser
+
+ dbg("%s", __func__);
+
+- if (serial == NULL)
+- return;
+-
+ for (i = 0; i < serial->num_ports; ++i) {
+ serial_table[serial->minor + i] = NULL;
+ }
+@@ -140,7 +137,8 @@ static void destroy_serial(struct kref *
+ serial->type->shutdown(serial);
+
+ /* return the minor range that this device had */
+- return_serial(serial);
++ if (serial->minor != SERIAL_TTY_NO_MINOR)
++ return_serial(serial);
+
+ for (i = 0; i < serial->num_ports; ++i)
+ serial->port[i]->open_count = 0;
+@@ -562,6 +560,7 @@ static struct usb_serial * create_serial
+ serial->interface = interface;
+ kref_init(&serial->kref);
+ mutex_init(&serial->disc_mutex);
++ serial->minor = SERIAL_TTY_NO_MINOR;
+
+ return serial;
+ }
+--- a/include/linux/usb/serial.h
++++ b/include/linux/usb/serial.h
+@@ -17,7 +17,8 @@
+ #include <linux/mutex.h>
+
+ #define SERIAL_TTY_MAJOR 188 /* Nice legal number now */
+-#define SERIAL_TTY_MINORS 255 /* loads of devices :) */
++#define SERIAL_TTY_MINORS 254 /* loads of devices :) */
++#define SERIAL_TTY_NO_MINOR 255 /* No minor was assigned */
+
+ /* The maximum number of ports one device can grab at once */
+ #define MAX_NUM_PORTS 8
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:20 2008
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 14 Aug 2008 03:55:07 GMT
+Subject: usb-storage: unusual_devs entries for iRiver T10 and Datafab CF+SM reader
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3t7Rc011754@hera.kernel.org>
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 368ee6469c327364ea10082a348f91c1f5ba47f7 upstream
+
+This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE
+flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card
+reader. Apparently these devices provide reasonable residue values
+for READ and WRITE operations, but not for others like INQUIRY or READ
+CAPACITY.
+
+This fixes the iRiver T10 problem reported in Bugzilla #11125.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/storage/unusual_devs.h | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -1187,6 +1187,13 @@ UNUSUAL_DEV( 0x07c4, 0xa400, 0x0000, 0x
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_FIX_INQUIRY ),
+
++/* Reported by Rauch Wolke <rauchwolke@gmx.net> */
++UNUSUAL_DEV( 0x07c4, 0xa4a5, 0x0000, 0xffff,
++ "Simple Tech/Datafab",
++ "CF+SM Reader",
++ US_SC_DEVICE, US_PR_DEVICE, NULL,
++ US_FL_IGNORE_RESIDUE ),
++
+ /* Casio QV 2x00/3x00/4000/8000 digital still cameras are not conformant
+ * to the USB storage specification in two ways:
+ * - They tell us they are using transport protocol CBI. In reality they
+@@ -1758,6 +1765,13 @@ UNUSUAL_DEV( 0x2770, 0x915d, 0x0010, 0x
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_FIX_CAPACITY ),
+
++/* Reported by Andrey Rahmatullin <wrar@altlinux.org> */
++UNUSUAL_DEV( 0x4102, 0x1020, 0x0100, 0x0100,
++ "iRiver",
++ "MP3 T10",
++ US_SC_DEVICE, US_PR_DEVICE, NULL,
++ US_FL_IGNORE_RESIDUE ),
++
+ /*
+ * David Härdeman <david@2gen.com>
+ * The key makes the SCSI stack print confusing (but harmless) messages
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Aug 13 20:55:21 2008
+From: Dave Jones <davej@redhat.com>
+Date: Thu, 14 Aug 2008 03:55:14 GMT
+Subject: USB: usb-storage: quirk around v1.11 firmware on Nikon D4
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808140355.m7E3tE3H011825@hera.kernel.org>
+
+From: Dave Jones <davej@redhat.com>
+
+commit b9a097f26e55968cbc52e30a4a2e73d32d7604ce upstream
+
+usb-storage: quirk around v1.11 firmware on Nikon D40
+
+https://bugzilla.redhat.com/show_bug.cgi?id=454028
+Just as in earlier firmware versions, we need to perform this
+quirk for the latest version too.
+
+Speculatively do the entry for the D80 too, as they seem to
+have the same firmware problems historically.
+
+Signed-off-by: Dave Jones <davej@redhat.com>
+Cc: Johannes Berg <johannes@sipsolutions.net>
+Cc: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/storage/unusual_devs.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -358,14 +358,14 @@ UNUSUAL_DEV( 0x04b0, 0x040f, 0x0100, 0x
+ US_FL_FIX_CAPACITY),
+
+ /* Reported by Emil Larsson <emil@swip.net> */
+-UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0110,
++UNUSUAL_DEV( 0x04b0, 0x0411, 0x0100, 0x0111,
+ "NIKON",
+ "NIKON DSC D80",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
+ US_FL_FIX_CAPACITY),
+
+ /* Reported by Ortwin Glueck <odi@odi.ch> */
+-UNUSUAL_DEV( 0x04b0, 0x0413, 0x0110, 0x0110,
++UNUSUAL_DEV( 0x04b0, 0x0413, 0x0110, 0x0111,
+ "NIKON",
+ "NIKON DSC D40",
+ US_SC_DEVICE, US_PR_DEVICE, NULL,
--- /dev/null
+From stable-bounces@linux.kernel.org Tue Aug 5 17:05:12 2008
+From: Ondrej Zajicek <santiago@crfreenet.org>
+Date: Wed, 6 Aug 2008 00:05:05 GMT
+Subject: vt8623fb: fix kernel oops
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200808060005.m76055Oq008078@hera.kernel.org>
+
+From: Ondrej Zajicek <santiago@crfreenet.org>
+
+commit 594a8819774b09ee5bf72d23300489459ff1f882 upstream
+
+commit 20e061fb750d36ec0ffcb2e44ed7dafa9018223b
+ Author: Ondrej Zajicek <santiago@crfreenet.org>
+ Date: Mon Apr 28 02:15:18 2008 -0700
+
+ fbdev: framebuffer_alloc() fixes
+
+ Correct the dev arg of framebuffer_alloc() in arkfb, s3fb and vt8623fb.
+
+causes a null-pointer deref because "info->dev is NULL, info was just
+kzallocated".
+
+Signed-off-by: Ondrej Zajicek <santiago@crfreenet.org>
+Reported-by: "MadLoisae@gmx.net" <MadLoisae@gmx.net>
+Tested-by: "MadLoisae@gmx.net" <MadLoisae@gmx.net>
+Cc: Alexey Dobriyan <adobriyan@gmail.com>
+Cc: "Antonino A. Daplas" <adaplas@pol.net>
+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/arkfb.c | 18 +++++++++---------
+ drivers/video/s3fb.c | 18 +++++++++---------
+ drivers/video/vt8623fb.c | 20 ++++++++++----------
+ 3 files changed, 28 insertions(+), 28 deletions(-)
+
+--- a/drivers/video/arkfb.c
++++ b/drivers/video/arkfb.c
+@@ -958,20 +958,20 @@ static int __devinit ark_pci_probe(struc
+ /* Prepare PCI device */
+ rc = pci_enable_device(dev);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot enable PCI device\n");
++ dev_err(info->device, "cannot enable PCI device\n");
+ goto err_enable_device;
+ }
+
+ rc = pci_request_regions(dev, "arkfb");
+ if (rc < 0) {
+- dev_err(info->dev, "cannot reserve framebuffer region\n");
++ dev_err(info->device, "cannot reserve framebuffer region\n");
+ goto err_request_regions;
+ }
+
+ par->dac = ics5342_init(ark_dac_read_regs, ark_dac_write_regs, info);
+ if (! par->dac) {
+ rc = -ENOMEM;
+- dev_err(info->dev, "RAMDAC initialization failed\n");
++ dev_err(info->device, "RAMDAC initialization failed\n");
+ goto err_dac;
+ }
+
+@@ -982,7 +982,7 @@ static int __devinit ark_pci_probe(struc
+ info->screen_base = pci_iomap(dev, 0, 0);
+ if (! info->screen_base) {
+ rc = -ENOMEM;
+- dev_err(info->dev, "iomap for framebuffer failed\n");
++ dev_err(info->device, "iomap for framebuffer failed\n");
+ goto err_iomap;
+ }
+
+@@ -1004,19 +1004,19 @@ static int __devinit ark_pci_probe(struc
+ rc = fb_find_mode(&(info->var), info, mode_option, NULL, 0, NULL, 8);
+ if (! ((rc == 1) || (rc == 2))) {
+ rc = -EINVAL;
+- dev_err(info->dev, "mode %s not found\n", mode_option);
++ dev_err(info->device, "mode %s not found\n", mode_option);
+ goto err_find_mode;
+ }
+
+ rc = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot allocate colormap\n");
++ dev_err(info->device, "cannot allocate colormap\n");
+ goto err_alloc_cmap;
+ }
+
+ rc = register_framebuffer(info);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot register framebugger\n");
++ dev_err(info->device, "cannot register framebugger\n");
+ goto err_reg_fb;
+ }
+
+@@ -1090,7 +1090,7 @@ static int ark_pci_suspend (struct pci_d
+ struct fb_info *info = pci_get_drvdata(dev);
+ struct arkfb_info *par = info->par;
+
+- dev_info(info->dev, "suspend\n");
++ dev_info(info->device, "suspend\n");
+
+ acquire_console_sem();
+ mutex_lock(&(par->open_lock));
+@@ -1121,7 +1121,7 @@ static int ark_pci_resume (struct pci_de
+ struct fb_info *info = pci_get_drvdata(dev);
+ struct arkfb_info *par = info->par;
+
+- dev_info(info->dev, "resume\n");
++ dev_info(info->device, "resume\n");
+
+ acquire_console_sem();
+ mutex_lock(&(par->open_lock));
+--- a/drivers/video/s3fb.c
++++ b/drivers/video/s3fb.c
+@@ -903,13 +903,13 @@ static int __devinit s3_pci_probe(struct
+ /* Prepare PCI device */
+ rc = pci_enable_device(dev);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot enable PCI device\n");
++ dev_err(info->device, "cannot enable PCI device\n");
+ goto err_enable_device;
+ }
+
+ rc = pci_request_regions(dev, "s3fb");
+ if (rc < 0) {
+- dev_err(info->dev, "cannot reserve framebuffer region\n");
++ dev_err(info->device, "cannot reserve framebuffer region\n");
+ goto err_request_regions;
+ }
+
+@@ -921,7 +921,7 @@ static int __devinit s3_pci_probe(struct
+ info->screen_base = pci_iomap(dev, 0, 0);
+ if (! info->screen_base) {
+ rc = -ENOMEM;
+- dev_err(info->dev, "iomap for framebuffer failed\n");
++ dev_err(info->device, "iomap for framebuffer failed\n");
+ goto err_iomap;
+ }
+
+@@ -965,19 +965,19 @@ static int __devinit s3_pci_probe(struct
+ rc = fb_find_mode(&(info->var), info, mode_option, NULL, 0, NULL, 8);
+ if (! ((rc == 1) || (rc == 2))) {
+ rc = -EINVAL;
+- dev_err(info->dev, "mode %s not found\n", mode_option);
++ dev_err(info->device, "mode %s not found\n", mode_option);
+ goto err_find_mode;
+ }
+
+ rc = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot allocate colormap\n");
++ dev_err(info->device, "cannot allocate colormap\n");
+ goto err_alloc_cmap;
+ }
+
+ rc = register_framebuffer(info);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot register framebuffer\n");
++ dev_err(info->device, "cannot register framebuffer\n");
+ goto err_reg_fb;
+ }
+
+@@ -1053,7 +1053,7 @@ static int s3_pci_suspend(struct pci_dev
+ struct fb_info *info = pci_get_drvdata(dev);
+ struct s3fb_info *par = info->par;
+
+- dev_info(info->dev, "suspend\n");
++ dev_info(info->device, "suspend\n");
+
+ acquire_console_sem();
+ mutex_lock(&(par->open_lock));
+@@ -1085,7 +1085,7 @@ static int s3_pci_resume(struct pci_dev*
+ struct s3fb_info *par = info->par;
+ int err;
+
+- dev_info(info->dev, "resume\n");
++ dev_info(info->device, "resume\n");
+
+ acquire_console_sem();
+ mutex_lock(&(par->open_lock));
+@@ -1102,7 +1102,7 @@ static int s3_pci_resume(struct pci_dev*
+ if (err) {
+ mutex_unlock(&(par->open_lock));
+ release_console_sem();
+- dev_err(info->dev, "error %d enabling device for resume\n", err);
++ dev_err(info->device, "error %d enabling device for resume\n", err);
+ return err;
+ }
+ pci_set_master(dev);
+--- a/drivers/video/vt8623fb.c
++++ b/drivers/video/vt8623fb.c
+@@ -677,13 +677,13 @@ static int __devinit vt8623_pci_probe(st
+
+ rc = pci_enable_device(dev);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot enable PCI device\n");
++ dev_err(info->device, "cannot enable PCI device\n");
+ goto err_enable_device;
+ }
+
+ rc = pci_request_regions(dev, "vt8623fb");
+ if (rc < 0) {
+- dev_err(info->dev, "cannot reserve framebuffer region\n");
++ dev_err(info->device, "cannot reserve framebuffer region\n");
+ goto err_request_regions;
+ }
+
+@@ -696,14 +696,14 @@ static int __devinit vt8623_pci_probe(st
+ info->screen_base = pci_iomap(dev, 0, 0);
+ if (! info->screen_base) {
+ rc = -ENOMEM;
+- dev_err(info->dev, "iomap for framebuffer failed\n");
++ dev_err(info->device, "iomap for framebuffer failed\n");
+ goto err_iomap_1;
+ }
+
+ par->mmio_base = pci_iomap(dev, 1, 0);
+ if (! par->mmio_base) {
+ rc = -ENOMEM;
+- dev_err(info->dev, "iomap for MMIO failed\n");
++ dev_err(info->device, "iomap for MMIO failed\n");
+ goto err_iomap_2;
+ }
+
+@@ -714,7 +714,7 @@ static int __devinit vt8623_pci_probe(st
+ if ((16 <= memsize1) && (memsize1 <= 64) && (memsize1 == memsize2))
+ info->screen_size = memsize1 << 20;
+ else {
+- dev_err(info->dev, "memory size detection failed (%x %x), suppose 16 MB\n", memsize1, memsize2);
++ dev_err(info->device, "memory size detection failed (%x %x), suppose 16 MB\n", memsize1, memsize2);
+ info->screen_size = 16 << 20;
+ }
+
+@@ -731,19 +731,19 @@ static int __devinit vt8623_pci_probe(st
+ rc = fb_find_mode(&(info->var), info, mode_option, NULL, 0, NULL, 8);
+ if (! ((rc == 1) || (rc == 2))) {
+ rc = -EINVAL;
+- dev_err(info->dev, "mode %s not found\n", mode_option);
++ dev_err(info->device, "mode %s not found\n", mode_option);
+ goto err_find_mode;
+ }
+
+ rc = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot allocate colormap\n");
++ dev_err(info->device, "cannot allocate colormap\n");
+ goto err_alloc_cmap;
+ }
+
+ rc = register_framebuffer(info);
+ if (rc < 0) {
+- dev_err(info->dev, "cannot register framebugger\n");
++ dev_err(info->device, "cannot register framebugger\n");
+ goto err_reg_fb;
+ }
+
+@@ -817,7 +817,7 @@ static int vt8623_pci_suspend(struct pci
+ struct fb_info *info = pci_get_drvdata(dev);
+ struct vt8623fb_info *par = info->par;
+
+- dev_info(info->dev, "suspend\n");
++ dev_info(info->device, "suspend\n");
+
+ acquire_console_sem();
+ mutex_lock(&(par->open_lock));
+@@ -848,7 +848,7 @@ static int vt8623_pci_resume(struct pci_
+ struct fb_info *info = pci_get_drvdata(dev);
+ struct vt8623fb_info *par = info->par;
+
+- dev_info(info->dev, "resume\n");
++ dev_info(info->device, "resume\n");
+
+ acquire_console_sem();
+ mutex_lock(&(par->open_lock));
projects / thirdparty / kernel / stable-queue.git / commitdiff
