kernel/linux.git, branch v2.6.32.23

Linux 2.6.32.23

2010-09-27T00:22:13+00:00

x86: Add memory modify constraints to xchg() and cmpxchg()

2010-09-27T00:21:43+00:00

commit 113fc5a6e8c2288619ff7e8187a6f556b7e0d372 upstream. [ Backport to .32 by Tomáš Janoušek ] xchg() and cmpxchg() modify their memory operands, not merely read them. For some versions of gcc the "memory" clobber has apparently dealt with the situation, but not for all. Originally-by: Linus Torvalds Signed-off-by: H. Peter Anvin Cc: Glauber Costa Cc: Avi Kivity Cc: Peter Palfrader Cc: Greg KH Cc: Alan Cox Cc: Zachary Amsden Cc: Marcelo Tosatti LKML-Reference: <4C4F7277.8050306@zytor.com> Signed-off-by: Greg Kroah-Hartman

alpha: Fix printk format errors

2010-09-27T00:21:43+00:00

commit 3e073367a57d41e506f20aebb98e308387ce3090 upstream. When compiling alpha generic build get errors such as: arch/alpha/kernel/err_marvel.c: In function ‘marvel_print_err_cyc’: arch/alpha/kernel/err_marvel.c:119: error: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘u64’ Replaced a number of %ld format specifiers with %lld since u64 is unsigned long long. Signed-off-by: Michael Cree Signed-off-by: Matt Turner Signed-off-by: Greg Kroah-Hartman

sis-agp: Remove SIS 760, handled by amd64-agp

2010-09-27T00:21:42+00:00

commit d831692a1a8e9ceaaa9bb16bb3fc503b7e372558 upstream. SIS 760 is listed in the device tables for both amd64-agp and sis-agp. amd64-agp is apparently preferable since it has workarounds for some BIOS misconfigurations that sis-agp doesn't handle. Signed-off-by: Ben Hutchings Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

MIPS: Sibyte: Fix M3 TLB exception handler workaround.

2010-09-27T00:21:40+00:00

commit 3d45285dd1ff4d4a1361b95e2d6508579a4402b5 upstream. The M3 workaround needs to cmpare the region and VPN2 fields only. Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets

2010-09-27T00:21:40+00:00

commit 750e519da7b3f470fe1b5b55c8d8f52d6d6371e4 upstream. PDC2026x chipsets need the same treatment as PDC20246 one. This is completely untested but will hopefully fix UDMA issues that people have been reporting against pata_pdc202xx_old for the last couple of years. Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards

2010-09-27T00:21:40+00:00

commit a75032e8772d13dab5e3501413d7e14a148281b4 upstream. On Monday 04 January 2010 02:30:24 pm Russell King wrote: > Found the problem - getting rid of the read of the alt status register > after the command has been written fixes the UDMA CRC errors on write: > > @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct > ata_taskfile *tf) > DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command); > > iowrite8(tf->command, ap->ioaddr.command_addr); > - ata_sff_pause(ap); > + ndelay(400); > +// ata_sff_pause(ap); > } > EXPORT_SYMBOL_GPL(ata_sff_exec_command); > > > This rather makes sense. The PDC20247 handles the UDMA part of the > protocol. It has no way to tell the PDC20246 to wait while it suspends > UDMA, so that a normal register access can take place - the 246 ploughs > on with the register access without any regard to the state of the 247. > > If the drive immediately starts the UDMA protocol after a write to the > command register (as it probably will for the DMA WRITE command), then > we'll be accessing the taskfile in the middle of the UDMA setup, which > can't be good. It's certainly a violation of the ATA specs. Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets. Debugged-by: Russell King Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

MIPS: uasm: Add OR instruction.

2010-09-27T00:21:39+00:00

commit 5808184f1b2fe06ef8a54a2b7fb1596d58098acf upstream. This is needed for the fix of the M3 workaround. Signed-off-by: Ralf Baechle [Backported by Aurelien Jarno ] Signed-off-by: Greg Kroah-Hartman

MIPS: Set io_map_base for several PCI bridges lacking it

2010-09-27T00:21:39+00:00

commit 8faf2e6c201d95b780cd3b4674b7a55ede6dcbbb upstream. Several MIPS platforms don't set pci_controller::io_map_base for their PCI bridges. This results in a panic in pci_iomap(). (The panic is conditional on CONFIG_PCI_DOMAINS, but that is now enabled for all PCI MIPS systems.) Signed-off-by: Ben Hutchings Cc: linux-mips@linux-mips.org Cc: Martin Michlmayr Cc: Aurelien Jarno Cc: 584784@bugs.debian.org Patchwork: https://patchwork.linux-mips.org/patch/1377/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman

MIPS: Quit using undefined behavior of ADDU in 64-bit atomic operations.

2010-09-27T00:21:39+00:00

commit f2a68272d799bf4092443357142f63b74f7669a1 upstream. For 64-bit, we must use DADDU and DSUBU. Signed-off-by: David Daney To: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/1483/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman