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

bonding: fix panic when taking bond interface down before removing module

2008-11-07T03:05:55+00:00

commit ce39a800ea87c655de49af021c8b20ee323cb40d upstream.

A panic was discovered with bonding when using mode 5 or 6 and trying to
remove the slaves from the bond after the interface was taken down.
When calling 'ifconfig bond0 down' the following happens:

    bond_close()
        bond_alb_deinitialize()
            tlb_deinitialize()
		kfree(bond_info->tx_hashtbl)
                bond_info->tx_hashtbl = NULL

Unfortunately if there are still slaves in the bond, when removing the
module the following happens:

    bonding_exit()
        bond_free_all()
            bond_release_all()
                bond_alb_deinit_slave()
                    tlb_clear_slave()
                        tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl
			u32 next_index = tx_hash_table[index].next

As you might guess we panic when trying to access a few entries into the
table that no longer exists.

I experimented with several options (like moving the calls to
tlb_deinitialize somewhere else), but it really makes the most sense to
be part of the bond_close routine.  It also didn't seem logical move
tlb_clear_slave around too much, so the simplest option seems to add a
check in tlb_clear_slave to make sure we haven't already wiped the
tx_hashtbl away before searching for all the non-existent hash-table
entries that used to point to the slave as the output interface.

Signed-off-by: Andy Gospodarek 
Signed-off-by: Jay Vosburgh 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

Input: atkbd - expand Latitude's force release quirk to other Dells

2008-11-07T03:05:54+00:00

commit 61579ba83934d397a4fa2bb7372de9ae112587d5 upstream.

Input: atkbd - expand Latitude's force release quirk to other Dells

Dell laptops fail to send key up events for several of their special
keys. There's an existing quirk in the kernel to handle this, but it's
limited to the Latitude range. This patch extends it to cover all
portable Dells.

Signed-off-by: Matthew Garrett 
Signed-off-by: Dmitry Torokhov 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ACPI: Clear WAK_STS on resume

2008-11-07T03:05:54+00:00

commit a68823ee5285e65b51ceb96f8b13a5b4f99a6888 upstream.

ACPI: Clear WAK_STS on resume

The leading other brand OS appears to clear the WAK_STS flag on resume.
When rebooted, certain BIOSes assume that the system is actually
resuming if it's still set and so fail to reboot correctly. Make sure
that it's cleared at resume time.

Comment clarified as suggested by Bob Moore

http://bugzilla.kernel.org/show_bug.cgi?id=11634

Signed-off-by: Matthew Garrett 
Signed-off-by: Andi Kleen 
Tested-by: Christian Borntraeger 
Tested-by: Romano Giannetti 
Signed-off-by: Len Brown 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism

2008-11-07T03:05:54+00:00

commit 8fd145917fb62368a9b80db59562c20576238f5a upstream

ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism

According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
whether the ACPI reboot mechanism is supported.

However, some boxes have this bit clear, have a valid
ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
mechanism that works for them after S3.

This suggests that other operating systems may not be checking
the RESET_REG_SUP bit, and are using other means to decide
whether to use the ACPI reboot mechanism or not.

Here we stop checking RESET_REG_SUP.
Instead, When acpi reboot is requested,
only the reset_register is checked. If the following
conditions are met, it indicates that the reset register is supported.
	a. reset_register is not zero
	b. the access width is eight
	c. the bit_offset is zero

http://bugzilla.kernel.org/show_bug.cgi?id=7299
http://bugzilla.kernel.org/show_bug.cgi?id=1148

Signed-off-by: Zhao Yakui 
Signed-off-by: Len Brown 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

libata: Fix LBA48 on pata_it821x RAID volumes.

2008-11-07T03:05:54+00:00

commit 054e5f616b5becdc096b793407dc33fe379749ac upstream

libata: Fix LBA48 on pata_it821x RAID volumes.

[http://lkml.org/lkml/2008/10/18/82]

Signed-off-by: Ondrej Zary 
Acked-by: Alan Cox 
Signed-off-by: Jeff Garzik 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Check for IBF=0 periodically if not in GPE mode

2008-11-07T03:05:52+00:00

commit c0ff17720ec5f42205b3d2ca03a18da0a8272976 upstream.

Signed-off-by: Alexey Starikovskiy 
Tested-by: Alan Jenkins 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Rename some variables

2008-11-07T03:05:52+00:00

commit 8463200a00fe2aea938b40173198a0983f2929ef upstream
(needed by the next patch)

No functional changes.

Signed-off-by: Alexey Starikovskiy 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: do transaction from interrupt context

2008-11-07T03:05:52+00:00

commit 7c6db4e050601f359081fde418ca6dc4fc2d0011 upstream.

It is easier and faster to do transaction directly from interrupt context
rather than waking control thread.
Also, cleaner GPE storm avoidance is implemented.
References: 	http://bugzilla.kernel.org/show_bug.cgi?id=9998
		http://bugzilla.kernel.org/show_bug.cgi?id=10724
		http://bugzilla.kernel.org/show_bug.cgi?id=10919
		http://bugzilla.kernel.org/show_bug.cgi?id=11309
		http://bugzilla.kernel.org/show_bug.cgi?id=11549

Signed-off-by: Alexey Starikovskiy 
Tested-by: Sitsofe Wheeler 
Signed-off-by: Len Brown 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

sata_nv: fix generic, nf2/3 detection regression

2008-11-07T03:05:51+00:00

commit 3c324283e6cdb79210cf7975c3e40d3ba3e672b2 upstream

All three flavors of sata_nv's are different in how their hardreset
behaves.

* generic: Hardreset is not reliable.  Link often doesn't come online
  after hardreset.

* nf2/3: A little bit better - link comes online with longer debounce
  timing.  However, nf2/3 can't reliable wait for the first D2H
  Register FIS, so it can't wait for device readiness or classify the
  device after hardreset.  Follow-up SRST required.

* ck804: Hardreset finally works.

The core layer change to prefer hardreset and follow up changes
exposed the above issues and caused various detection regressions for
all three flavors.  This patch, hopefully, fixes all the known issues
and should make sata_nv error handling more reliable.

Signed-off-by: Tejun Heo 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

sata_promise: add ATA engine reset to reset ops

2008-11-07T03:05:51+00:00

commit cadef677e4a9b9c1d069675043767df486782986 upstream

Promise ATA engines need to be reset when errors occur.
That's currently done for errors detected by sata_promise itself,
but it's not done for errors like timeouts detected outside of
the low-level driver.

The effect of this omission is that a timeout tends to result
in a sequence of failed COMRESETs after which libata EH gives
up and disables the port. At that point the port's ATA engine
hangs and even reloading the driver will not resume it.

To fix this, make sata_promise override ->hardreset on SATA
ports with code which calls pdc_reset_port() on the port in
question before calling libata's hardreset. PATA ports don't
use ->hardreset, so for those we override ->softreset instead.

Signed-off-by: Mikael Pettersson 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman