[patch 00/12] 2.6.22-stable review

[patch 00/12] 2.6.22-stable review

[Greg KH]

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

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

Responses should be made by Wed, August 15 00:00:00 UTC.  Anything
received after that time might be too late.

thanks,

greg k-h

[patch 01/12] fix oops in __audit_signal_info()

[Greg KH]

[-- Attachment #1: fix-oops-in-__audit_signal_info.patch --]
[-- Type: text/plain, Size: 1588 bytes --]


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

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


From: Al Viro <viro@ftp.linux.org.uk>

	Check for audit_signals is misplaced and check for
audit_dummy_context() is missing; as the result, if we send
signal to auditd from task with NULL ->audit_context while
we have audit_signals != 0 we end up with an oops.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/auditsc.c |   22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1998,19 +1998,19 @@ int __audit_signal_info(int sig, struct 
 	extern uid_t audit_sig_uid;
 	extern u32 audit_sig_sid;
 
-	if (audit_pid && t->tgid == audit_pid &&
-	    (sig == SIGTERM || sig == SIGHUP || sig == SIGUSR1)) {
-		audit_sig_pid = tsk->pid;
-		if (ctx)
-			audit_sig_uid = ctx->loginuid;
-		else
-			audit_sig_uid = tsk->uid;
-		selinux_get_task_sid(tsk, &audit_sig_sid);
+	if (audit_pid && t->tgid == audit_pid) {
+		if (sig == SIGTERM || sig == SIGHUP || sig == SIGUSR1) {
+			audit_sig_pid = tsk->pid;
+			if (ctx)
+				audit_sig_uid = ctx->loginuid;
+			else
+				audit_sig_uid = tsk->uid;
+			selinux_get_task_sid(tsk, &audit_sig_sid);
+		}
+		if (!audit_signals || audit_dummy_context())
+			return 0;
 	}
 
-	if (!audit_signals) /* audit_context checked in wrapper */
-		return 0;
-
 	/* optimize the common case by putting first signal recipient directly
 	 * in audit_context */
 	if (!ctx->target_pid) {

-- 

[patch 02/12] random: fix bound check ordering (CVE-2007-3105)

[Greg KH]

[-- Attachment #1: random-fix-bound-check-ordering.patch --]
[-- Type: text/plain, Size: 1441 bytes --]

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

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

From: Matt Mackall <mpm@selenic.com>

If root raised the default wakeup threshold over the size of the
output pool, the pool transfer function could overflow the stack with
RNG bytes, causing a DoS or potential privilege escalation.

(Bug reported by the PaX Team <pageexec@freemail.hu>)

Cc: Theodore Tso <tytso@mit.edu>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/random.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -693,9 +693,14 @@ static void xfer_secondary_pool(struct e
 
 	if (r->pull && r->entropy_count < nbytes * 8 &&
 	    r->entropy_count < r->poolinfo->POOLBITS) {
-		int bytes = max_t(int, random_read_wakeup_thresh / 8,
-				min_t(int, nbytes, sizeof(tmp)));
+		/* If we're limited, always leave two wakeup worth's BITS */
 		int rsvd = r->limit ? 0 : random_read_wakeup_thresh/4;
+		int bytes = nbytes;
+
+		/* pull at least as many as BYTES as wakeup BITS */
+		bytes = max_t(int, bytes, random_read_wakeup_thresh / 8);
+		/* but never more than the buffer size */
+		bytes = min_t(int, bytes, sizeof(tmp));
 
 		DEBUG_ENT("going to reseed %s with %d bits "
 			  "(%d of %d requested)\n",

-- 

[patch 03/12] softmac: Fix deadlock of wx_set_essid with assoc work

[Greg KH]

[-- Attachment #1: softmac-fix-deadlock-of-wx_set_essid-with-assoc-work.patch --]
[-- Type: text/plain, Size: 1658 bytes --]

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

------------------
From: Michael Buesch <mb@bu3sch.de>

The essid wireless extension does deadlock against the assoc mutex,
as we don't unlock the assoc mutex when flushing the workqueue, which
also holds the lock.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ieee80211/softmac/ieee80211softmac_wx.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -74,8 +74,8 @@ ieee80211softmac_wx_set_essid(struct net
 	struct ieee80211softmac_auth_queue_item *authptr;
 	int length = 0;
 
+check_assoc_again:
 	mutex_lock(&sm->associnfo.mutex);
-
 	/* Check if we're already associating to this or another network
 	 * If it's another network, cancel and start over with our new network
 	 * If it's our network, ignore the change, we're already doing it!
@@ -98,13 +98,18 @@ ieee80211softmac_wx_set_essid(struct net
 				cancel_delayed_work(&authptr->work);
 			sm->associnfo.bssvalid = 0;
 			sm->associnfo.bssfixed = 0;
-			flush_scheduled_work();
 			sm->associnfo.associating = 0;
 			sm->associnfo.associated = 0;
+			/* We must unlock to avoid deadlocks with the assoc workqueue
+			 * on the associnfo.mutex */
+			mutex_unlock(&sm->associnfo.mutex);
+			flush_scheduled_work();
+			/* Avoid race! Check assoc status again. Maybe someone started an
+			 * association while we flushed. */
+			goto check_assoc_again;
 		}
 	}
 
-
 	sm->associnfo.static_essid = 0;
 	sm->associnfo.assoc_wait = 0;
 

-- 

[patch 04/12] ata_piix: update map 10b for ich8m

[Greg KH]

[-- Attachment #1: ata_piix-update-map-10b-for-ich8m.patch --]
[-- Type: text/plain, Size: 863 bytes --]

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

------------------
From: Tejun Heo <htejun@gmail.com>

Fix map entry 10b for ich8.  It's [P0 P2 IDE IDE] like ich6 / ich6m.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Acked-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -428,7 +428,7 @@ static const struct piix_map_db ich8_map
 		/* PM   PS   SM   SS       MAP */
 		{  P0,  P2,  P1,  P3 }, /* 00b (hardwired when in AHCI) */
 		{  RV,  RV,  RV,  RV },
-		{  IDE,  IDE,  NA,  NA }, /* 10b (IDE mode) */
+		{  P0,  P2, IDE, IDE }, /* 10b (IDE mode) */
 		{  RV,  RV,  RV,  RV },
 	},
 };

-- 

[patch 05/12] PPC: Revert "Dont complain if size-cells == 0 in prom_parse()"

[Greg KH]

[-- Attachment #1: ppc-revert-don-t-complain-if-size-cells-0-in-prom_parse.patch --]
[-- Type: text/plain, Size: 1459 bytes --]

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

------------------
From: Paul Mackerras <paulus@samba.org>

This reverts commit fd6e9d3945ee122eb513ada8b17296d243c1ce5e.

Having #size-cells == 0 in a node indicates that things under the
node aren't directly accessible, and therefore we shouldn't try to
translate addresses for devices under the node into CPU physical
addresses.

Some drivers, such as the nvram driver for powermacs, rely on
of_address_to_resource failing if they are called for a node
representing a device whose resources aren't directly accessible
by the CPU.  These drivers were broken by commit fd6e9d39,
resulting in the "Lombard" powerbook hanging early in the boot
process.

stable team, this patch is equivalent to commit

77926826f301fbd8ed96d3cd9ff17a5b59560dfb

Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -24,7 +24,7 @@
 /* Max address size we deal with */
 #define OF_MAX_ADDR_CELLS	4
 #define OF_CHECK_COUNTS(na, ns)	((na) > 0 && (na) <= OF_MAX_ADDR_CELLS && \
-			(ns) >= 0)
+			(ns) > 0)
 
 static struct of_bus *of_match_bus(struct device_node *np);
 static int __of_address_to_resource(struct device_node *dev,

-- 

[patch 07/12] powerpc: Fix size check for hugetlbfs

[Greg KH]

[-- Attachment #1: powerpc-fix-size-check-for-hugetlbfs.patch --]
[-- Type: text/plain, Size: 1147 bytes --]

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

------------------
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>

My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/mm/slice.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
 
 	if (len > mm->task_size)
 		return -ENOMEM;
+	if (len & ((1ul << pshift) - 1))
+		return -EINVAL;
 	if (fixed && (addr & ((1ul << pshift) - 1)))
 		return -EINVAL;
 	if (fixed && addr > (mm->task_size - len))

-- 

Re: [patch 07/12] powerpc: Fix size check for hugetlbfs

[David Gibson]

On Tue, Aug 14, 2007 at 12:29:18AM -0700, Greg KH wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> 
> My "slices" address space management code that was added in 2.6.22
> implementation of get_unmapped_area() doesn't properly check that the
> size is a multiple of the requested page size. This allows userland to
> create VMAs that aren't a multiple of the huge page size with hugetlbfs
> (since hugetlbfs entirely relies on get_unmapped_area() to do that
> checking) which leads to a kernel BUG() when such areas are torn down.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Acked-by: David Gibson <david@gibson.dropbear.id.au>

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[patch 06/12] PPC: Revert "Add mdio to bus scan id list for platforms with QE UEC"

[Greg KH]

[-- Attachment #1: ppc-revert-add-mdio-to-bus-scan-id-list-for-platforms-with-qe-uec.patch --]
[-- Type: text/plain, Size: 2107 bytes --]


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

------------------
From: Kim Phillips <kim.phillips@freescale.com>

This reverts commit 3baee955953957be5496cd28e9c544d9db214262.

this was a mistake from the start; I added mdio type to the bus
scan list early on in my ucc_geth migrate to phylib development,
which is just pure wrong (the ucc_geth_mii driver creates the mii
bus and the PHY layer handles PHY enumeration without translation).

this accompanies commit 77926826f301fbd8ed96d3cd9ff17a5b59560dfb:

 Revert "[POWERPC] Don't complain if size-cells == 0 in prom_parse()"

which was basically trying to hide a symptom of the original mistake
this revert fixes.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/platforms/83xx/mpc832x_mds.c |    1 -
 arch/powerpc/platforms/83xx/mpc832x_rdb.c |    1 -
 arch/powerpc/platforms/83xx/mpc836x_mds.c |    1 -
 arch/powerpc/platforms/85xx/mpc85xx_mds.c |    1 -
 4 files changed, 4 deletions(-)

--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -111,7 +111,6 @@ static struct of_device_id mpc832x_ids[]
 	{ .type = "soc", },
 	{ .compatible = "soc", },
 	{ .type = "qe", },
-	{ .type = "mdio", },
 	{},
 };
 
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -75,7 +75,6 @@ static struct of_device_id mpc832x_ids[]
 	{ .type = "soc", },
 	{ .compatible = "soc", },
 	{ .type = "qe", },
-	{ .type = "mdio", },
 	{},
 };
 
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -118,7 +118,6 @@ static struct of_device_id mpc836x_ids[]
 	{ .type = "soc", },
 	{ .compatible = "soc", },
 	{ .type = "qe", },
-	{ .type = "mdio", },
 	{},
 };
 
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -147,7 +147,6 @@ static struct of_device_id mpc85xx_ids[]
 	{ .type = "soc", },
 	{ .compatible = "soc", },
 	{ .type = "qe", },
-	{ .type = "mdio", },
 	{},
 };
 

-- 

[patch 08/12] direct-io: fix error-path crashes

[Greg KH]

[-- Attachment #1: direct-io-fix-error-path-crashes.patch --]
[-- Type: text/plain, Size: 1161 bytes --]

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

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

From: Badari Pulavarty <pbadari@us.ibm.com>

Need to initialize map_bh.b_state to zero.  Otherwise, in case of a faulty
user-buffer its possible to go into dio_zero_block() and submit a page by
mistake - since it checks for buffer_new().

http://marc.info/?l=linux-kernel&m=118551339032528&w=2

akpm: Linus had a (better) patch to just do a kzalloc() in there, but it got
lost.  Probably this version is better for -stable anwyay.

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Acked-by: Joe Jin <joe.jin@oracle.com>
Acked-by: Zach Brown <zach.brown@oracle.com>
Cc: gurudas pai <gurudas.pai@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/direct-io.c |    1 +
 1 file changed, 1 insertion(+)

--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -974,6 +974,7 @@ direct_io_worker(int rw, struct kiocb *i
 	dio->get_block = get_block;
 	dio->end_io = end_io;
 	dio->map_bh.b_private = NULL;
+	dio->map_bh.b_state = 0;
 	dio->final_block_in_bio = -1;
 	dio->next_block_for_io = -1;
 

-- 

[patch 12/12] CPUFREQ: ondemand: add a check to avoid negative load calculation

[Greg KH]

[-- Attachment #1: cpufreq-ondemand-add-a-check-to-avoid-negative-load-calculation.patch --]
[-- Type: text/plain, Size: 1308 bytes --]

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

------------------
From: Venki Pallipadi <venkatesh.pallipadi@intel.com>

Due to rounding and inexact jiffy accounting, idle_ticks can sometimes
be higher than total_ticks. Make sure those cases are handled as
zero load case.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/cpufreq/cpufreq_ondemand.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -335,7 +335,7 @@ static struct attribute_group dbs_attr_g
 static void dbs_check_cpu(struct cpu_dbs_info_s *this_dbs_info)
 {
 	unsigned int idle_ticks, total_ticks;
-	unsigned int load;
+	unsigned int load = 0;
 	cputime64_t cur_jiffies;
 
 	struct cpufreq_policy *policy;
@@ -381,7 +381,8 @@ static void dbs_check_cpu(struct cpu_dbs
 		if (tmp_idle_ticks < idle_ticks)
 			idle_ticks = tmp_idle_ticks;
 	}
-	load = (100 * (total_ticks - idle_ticks)) / total_ticks;
+	if (likely(total_ticks > idle_ticks))
+		load = (100 * (total_ticks - idle_ticks)) / total_ticks;
 
 	/* Check for frequency increase */
 	if (load > dbs_tuners_ins.up_threshold) {

-- 

[patch 11/12] CPUFREQ: ondemand: fix tickless accounting and software coordination bug

[Greg KH]

[-- Attachment #1: cpufreq-ondemand-fix-tickless-accounting-and-software-coordination-bug.patch --]
[-- Type: text/plain, Size: 2523 bytes --]

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

------------------
From: Venki Pallipadi <venkatesh.pallipadi@intel.com>

With tickless kernel and software coordination os P-states, ondemand
can look at wrong idle statistics. This can happen when ondemand sampling
is happening on CPU 0 and due to software coordination sampling also looks at
utilization of CPU 1. If CPU 1 is in tickless state at that moment, its idle
statistics will not be uptodate and CPU 0 thinks CPU 1 is idle for less
amount of time than it actually is.

This can be resolved by looking at all the busy times of CPUs, which is
accurate, even with tickless, and use that to determine idle time in a
round about way (total time - busy time).

Thanks to Arjan for originally reporting the ondemand bug on
Lenovo T61.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/cpufreq/cpufreq_ondemand.c |   25 ++++++++++++++++++-------
 1 file changed, 18 insertions(+), 7 deletions(-)

--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -96,15 +96,25 @@ static struct dbs_tuners {
 
 static inline cputime64_t get_cpu_idle_time(unsigned int cpu)
 {
-	cputime64_t retval;
+	cputime64_t idle_time;
+	cputime64_t cur_jiffies;
+	cputime64_t busy_time;
 
-	retval = cputime64_add(kstat_cpu(cpu).cpustat.idle,
-			kstat_cpu(cpu).cpustat.iowait);
+	cur_jiffies = jiffies64_to_cputime64(get_jiffies_64());
+	busy_time = cputime64_add(kstat_cpu(cpu).cpustat.user,
+			kstat_cpu(cpu).cpustat.system);
 
-	if (dbs_tuners_ins.ignore_nice)
-		retval = cputime64_add(retval, kstat_cpu(cpu).cpustat.nice);
+	busy_time = cputime64_add(busy_time, kstat_cpu(cpu).cpustat.irq);
+	busy_time = cputime64_add(busy_time, kstat_cpu(cpu).cpustat.softirq);
+	busy_time = cputime64_add(busy_time, kstat_cpu(cpu).cpustat.steal);
 
-	return retval;
+	if (!dbs_tuners_ins.ignore_nice) {
+		busy_time = cputime64_add(busy_time,
+				kstat_cpu(cpu).cpustat.nice);
+	}
+
+	idle_time = cputime64_sub(cur_jiffies, busy_time);
+	return idle_time;
 }
 
 /*
@@ -339,7 +349,8 @@ static void dbs_check_cpu(struct cpu_dbs
 	cur_jiffies = jiffies64_to_cputime64(get_jiffies_64());
 	total_ticks = (unsigned int) cputime64_sub(cur_jiffies,
 			this_dbs_info->prev_cpu_wall);
-	this_dbs_info->prev_cpu_wall = cur_jiffies;
+	this_dbs_info->prev_cpu_wall = get_jiffies_64();
+
 	if (!total_ticks)
 		return;
 	/*

-- 

[patch 10/12] pata_atiixp: add SB700 PCI ID

[Greg KH]

[-- Attachment #1: pata_atiixp-add-sb700-pci-id.patch --]
[-- Type: text/plain, Size: 753 bytes --]

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

------------------
From: Jeff Garzik <jeff@garzik.org>

[libata] pata_atiixp: add SB700 PCI ID

>From AMD.

Signed-off-by: Jeff Garzik <jeff@garzik.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ata/pata_atiixp.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -285,6 +285,7 @@ static const struct pci_device_id atiixp
 	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP300_IDE), },
 	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP400_IDE), },
 	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP600_IDE), },
+	{ PCI_VDEVICE(ATI, PCI_DEVICE_ID_ATI_IXP700_IDE), },
 
 	{ },
 };

-- 

[patch 09/12] stifb: detect cards in double buffer mode more reliably

[Greg KH]

[-- Attachment #1: stifb-detect-cards-in-double-buffer-mode-more-reliably.patch --]
[-- Type: text/plain, Size: 2641 bytes --]

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

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

From: Helge Deller <deller@gmx.de>

Visualize-EG, Graffiti and A4450A graphics cards on PARISC can
be configured in double-buffer and standard mode, but the stifb
driver supports standard mode only.
This patch detects double-buffered cards more reliable.

It is a real bugfix for a very nasty problem for all parisc users which have
wrongly configured their graphic card.  The problem: The stifb graphics driver
will not detect that the card is wrongly configured and then nevertheless just
enables the graphics mode, which it shouldn't.  In the end, the user will see
no further updates / boot messages on the screen.

We had documented this problem already on our FAQ
(http://parisc-linux.org/faq/index.html#viseg "Why do I get corrupted graphics
with my Vis-EG/Graffiti/A4450A card?") but people still run into this problem.
 So having this fix in as early as possible can help us.

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/stifb.c |   19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

--- a/drivers/video/stifb.c
+++ b/drivers/video/stifb.c
@@ -1100,13 +1100,18 @@ stifb_init_fb(struct sti_struct *sti, in
 	/* only supported cards are allowed */
 	switch (fb->id) {
 	case CRT_ID_VISUALIZE_EG:
-		/* look for a double buffering device like e.g. the 
-		   "INTERNAL_EG_DX1024" in the RDI precisionbook laptop
-		   which won't work. The same device in non-double 
-		   buffering mode returns "INTERNAL_EG_X1024". */
-		if (strstr(sti->outptr.dev_name, "EG_DX")) {
-		   printk(KERN_WARNING 
-			"stifb: ignoring '%s'. Disable double buffering in IPL menu.\n",
+		/* Visualize cards can run either in "double buffer" or
+ 		  "standard" mode. Depending on the mode, the card reports
+		  a different device name, e.g. "INTERNAL_EG_DX1024" in double
+		  buffer mode and "INTERNAL_EG_X1024" in standard mode.
+		  Since this driver only supports standard mode, we check
+		  if the device name contains the string "DX" and tell the
+		  user how to reconfigure the card. */
+		if (strstr(sti->outptr.dev_name, "DX")) {
+		   printk(KERN_WARNING "WARNING: stifb framebuffer driver does not "
+			"support '%s' in double-buffer mode.\n"
+			KERN_WARNING "WARNING: Please disable the double-buffer mode "
+			"in IPL menu (the PARISC-BIOS).\n",
 			sti->outptr.dev_name);
 		   goto out_err0;
 		}

-- 

Re: [patch 00/12] 2.6.22-stable review

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

Am Dienstag 14 August 2007 schrieb Greg KH:
> This is the start of the stable review cycle for the 2.6.22.3 release.

You missed this one: http://lkml.org/lkml/2007/8/10/296

The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix 
in .3...

bye,
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [patch 00/12] 2.6.22-stable review

[Greg KH]

On Tue, Aug 14, 2007 at 06:13:34PM +0200, Prakash Punnoor wrote:
> Am Dienstag 14 August 2007 schrieb Greg KH:
> > This is the start of the stable review cycle for the 2.6.22.3 release.
> 
> You missed this one: http://lkml.org/lkml/2007/8/10/296
> 
> The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix 
> in .3...

I asked for clarification about that patch, if it is really needed and
matters, yet did not recieve any response yet.

thanks,

greg k-h

Re: [patch 00/12] 2.6.22-stable review

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Am Dienstag 14 August 2007 schrieb Greg KH:
> On Tue, Aug 14, 2007 at 06:13:34PM +0200, Prakash Punnoor wrote:
> > Am Dienstag 14 August 2007 schrieb Greg KH:
> > > This is the start of the stable review cycle for the 2.6.22.3 release.
> >
> > You missed this one: http://lkml.org/lkml/2007/8/10/296
> >
> > The buggy patch was introduced in 2.6.22.2, so it wouldn't be bad to fix
> > in .3...
>
> I asked for clarification about that patch, if it is really needed and
> matters, yet did not recieve any response yet.

Well, I can't speak for the author, but I at least would find it disturbing if 
some random values would be written into random registers of my hardware, 
when they were meant for a different hardware...

-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]