linux-toradex.git/drivers, branch v2.6.25.14

ath5k: don't enable MSI, we cannot handle it yet

2008-08-01T18:51:00+00:00

commit 256b152b005e319f985f50f2a910a75ba0def74f upstream

MSI is a nice thing, but we cannot enable it without changing the
interrupt handler.  If we do it, we break MSI capable hardware,
specifically AR5006 chipset.

Signed-off-by: Pavel Roskin 
Acked-by: Nick Kossifidis 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: Release mutex in error handling code

2008-08-01T18:50:59+00:00

commit 4104863fb4a724723d1d5f3cba9d3c5084087e45 upstream

The mutex is released on a successful return, so it would seem that it
should be released on an error return as well.

The semantic patch finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// 
@@
expression l;
@@

mutex_lock(l);
.. when != mutex_unlock(l)
    when any
    when strict
(
if (...) { ... when != mutex_unlock(l)
+   mutex_unlock(l);
    return ...;
}
|
mutex_unlock(l);
)
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T18:50:58+00:00

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger 
Cc: Andi Kleen 
Cc: Len Brown 
Cc: Dave Jones 
Cc: Ingo Molnar 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ixgbe: remove device ID for unsupported device

2008-08-01T18:50:56+00:00

commit bb5d10ac8cc315d53306963001fe650d88a1cbb2 upstream

The ixgbe driver was untested with device ID 8086:10c8 but still advertises
support.  Currently if this device is present in the system when the driver
is loaded, the system will panic.
Remove this device ID until full support can be tested with available
hardware.  This patch is necessary for 2.6.24, 2.6.25 and 2.6.26

Signed-off-by: Jesse Brandeburg 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

mpc52xx_psc_spi: fix block transfer

2008-08-01T18:50:54+00:00

commit 9a7867e1b34c3575e7e76a05c0c54c6edbdae2a4 upstream

The block transfer routine in the mpc52xx psc spi driver misinterpret
the datasheet.  According to the processor datasheet the chipselect is
held as long as the EOF is not written.

Theoretically blocks of any sizes can be transferred in this way.  The
old routine however writes an EOF after every word, which has the size
of size_of_word.  This makes the transfer slow.

Also fixed some duplicate code.

Signed-off-by: Luotao Fu 
Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ahci: retry enabling AHCI a few times before spitting out WARN_ON()

2008-08-01T18:50:50+00:00

commit 15fe982e429e0e6b7466719acb6cfd9dbfe47f0c upstream

ahci: retry enabling AHCI a few times before spitting out WARN_ON()

Some chips need AHCI_EN set more than once to actually set it.  Try a
few times before giving up and spitting out WARN_ON().

Signed-off-by: Tejun Heo 
Cc: Peer Chen 
Cc: Volker Armin Hemmann 
Signed-off-by: Jeff Garzik 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ide-cd: fix oops when using growisofs

2008-08-01T18:50:46+00:00

commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667 upstream

cdrom_read_capacity() will blindly return the capacity from the device
without sanity-checking it.  This later causes code in fs/buffer.c to
oops.

Fix this by checking that the device is telling us sensible things.

From: Jens Axboe 
Cc: Michael Buesch 
Cc: Jan Kara 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Signed-off-by: Andrew Morton 
[bart: print device name instead of driver name]
Signed-off-by: Bartlomiej Zolnierkiewicz 
[harvey: blocklen is a big-endian value]
Signed-off-by: Harvey Harrison 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman

pata_atiixp: Don't disable

2008-08-01T18:50:44+00:00

Commit 05177f178efe1459d2d0ac05430027ba201889a4 upstream

pata_atiixp: Don't disable

A couple of distributions (Fedora, Ubuntu) were having weird problems with the
ATI IXP series PATA controllers being reported as simplex.  At the heart of
the problem is that both distros ignored the recommendations to load pata_acpi
and ata_generic *AFTER* specific host drivers.

The underlying cause however is that if you D3 and then D0 an ATI IXP it
helpfully throws away some configuration and won't let you rewrite it.

Add checks to ata_generic and pata_acpi to pin ATIIXP devices.  Possibly the
real answer here is to quirk them and pin them, but right now we can't do that
before they've been pcim_enable()'d by a driver.

I'm indebted to David Gero for this.  His bug report not only reported the
problem but identified the cause correctly and he had tested the right values
to prove what was going on

[If you backport this for 2.6.24 you will need to pull in the 2.6.25
removal of the bogus WARN_ON() in pcim_enagle]

Signed-off-by: Alan Cox 
Tested-by: David Gero 
Signed-off-by: Andrew Morton 
Signed-off-by: Jeff Garzik

pppoe: Unshare skb before anything else

2008-07-28T17:58:17+00:00

[ Upstream commit bc6cffd177f9266af38dba96a2cea06c1e7ff932 ]

We need to unshare the skb first as otherwise pskb_may_pull may
write to a shared skb which could be bad.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net pppoe: Check packet length on all receive paths

2008-07-28T17:58:17+00:00

[ Upstream commit 392fdb0e35055b96faa9c1cd6ab537805337cdce ]

The length field in the PPPOE header wasn't checked completely.
This patch causes all packets shorter than the declared length
to be dropped.

It also changes the memcpy_toiovec call to skb_copy_datagram_iovec
so that paged packets (rare for PPPOE) are handled properly.

Thanks to Ilja of the Netric Security Team for discovering and
reporting this bug, and Chris Wright for the total_len check.

[ Incorporate warning fix from Stephen Hemminger. -DaveM ]

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman