linux.git/include/asm-generic, branch v2.6.21

[PATCH] Proper fix for highmem kmap_atomic functions for VMI for 2.6.21

2007-04-09T02:47:55+00:00

Since lazy MMU batching mode still allows interrupts to enter, it is
possible for interrupt handlers to try to use kmap_atomic, which fails when
lazy mode is active, since the PTE update to highmem will be delayed.  The
best workaround is to issue an explicit flush in kmap_atomic_functions
case; this is the only way nested PTE updates can happen in the interrupt
handler.

Thanks to Jeremy Fitzhardinge for noting the bug and suggestions on a fix.

This patch gets reverted again when we start 2.6.22 and the bug gets fixed
differently.

Signed-off-by: Zachary Amsden 
Cc: Andi Kleen 
Cc: Jeremy Fitzhardinge 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "[PATCH] LOG2: Alter get_order() so that it can make use of ilog2() on a constant"

2007-03-07T03:38:01+00:00

This reverts commit 39d61db0edb34d60b83c5e0d62d0e906578cc707.

The commit was buggy in multiple ways:
 - the conversion to ilog2() was incorrect to begin with
 - it tested the wrong #defines, so on all architectures but FRV you'd
   never see the bug except for constant arguments.
 - the new "get_order()" macro used its arguments multiple times, and
   didn't even parenthesize them properly
 - despite the comments, it was not true that you could use it for
   constant initializers, since not all architectures even use the
   generic page.h header file.

All of the problems are individually fixable, but it all boils down to:
better just revert it, and re-do it from scratch.

Cc: David Howells 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] i386: paravirt CPU hypercall batching mode

2007-02-13T12:26:21+00:00

The VMI ROM has a mode where hypercalls can be queued and batched.  This turns
out to be a significant win during context switch, but must be done at a
specific point before side effects to CPU state are visible to subsequent
instructions.  This is similar to the MMU batching hooks already provided.
The same hooks could be used by the Xen backend to implement a context switch
multicall.

To explain a bit more about lazy modes in the paravirt patches, basically, the
idea is that only one of lazy CPU or MMU mode can be active at any given time.
 Lazy MMU mode is similar to this lazy CPU mode, and allows for batching of
multiple PTE updates (say, inside a remap loop), but to avoid keeping some
kind of state machine about when to flush cpu or mmu updates, we just allow
one or the other to be active.  Although there is no real reason a more
comprehensive scheme could not be implemented, there is also no demonstrated
need for this extra complexity.

Signed-off-by: Zachary Amsden 
Signed-off-by: Andi Kleen 
Cc: Andi Kleen 
Cc: Jeremy Fitzhardinge 
Cc: Rusty Russell 
Cc: Chris Wright 
Signed-off-by: Andrew Morton

[PATCH] GPIO core

2007-02-12T17:48:34+00:00

This defines a simple and minimalist programming interface for GPIO APIs:

  - Documentation/gpio.txt ... describes things (read it)

  - include/asm-arm/gpio.h ... defines the ARM hook, which just punts
    to  for any implementation

  - include/asm-generic/gpio.h ... implement "can sleep" variants as calling
    the normal ones, for systems that don't handle i2c expanders.

The immediate need for such a cross-architecture API convention is to support
drivers that work the same on AT91 ARM and AVR32 AP7000 chips, which embed many
of the same controllers but have different CPUs.  However, several other users
have been reported, including a driver for a hardware watchdog chip and some
handhelds.org multi-CPU button drivers.

Signed-off-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] one more iomap s390 build fix

2007-02-12T04:06:39+00:00

Commit 9ac7849e35f705830f7b016ff272b0ff1f7ff759 causes this on S390:

  drivers/built-in.o: In function `dmam_noncoherent_release':
    dma-mapping.c:(.text+0x1515c): undefined reference to `dma_free_noncoherent'
  drivers/built-in.o: In function `dmam_free_noncoherent':
    undefined reference to `dma_free_noncoherent'
  drivers/built-in.o: In function `dmam_alloc_noncoherent':
    undefined reference to `dma_alloc_noncoherent'
  make: *** [.tmp_vmlinux1] Error 1

Cc: Tejun Heo 
Acked-by: Jeff Garzik 
Cc: Martin Schwidefsky 
Signed-off-by: Heiko Carstens 
Signed-off-by: Linus Torvalds

[PATCH] typeof __page_to_pfn with SPARSEMEM=y

2007-02-11T18:51:17+00:00

With CONFIG_SPARSEMEM=y:

mm/rmap.c:579: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'int'

Make __page_to_pfn() return unsigned long.

Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Remove final references to deprecated "MAP_ANON" page protection flag

2007-02-11T18:51:17+00:00

Remove the last vestiges of the long-deprecated "MAP_ANON" page protection
flag: use "MAP_ANONYMOUS" instead.

Signed-off-by: Robert P. J. Day 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Fix Maple PATA IRQ assignment.

2007-01-26T22:27:40+00:00

On the Maple board, the AMD8111 IDE is in legacy mode... except that it
appears on IRQ 20 instead of IRQ 15. For drivers/ide this was handled by
the architecture's "pci_get_legacy_ide_irq()" function, but in libata we
just hard-code the numbers 14 and 15.

This patch provides asm-powerpc/libata-portmap.h which maps the IRQ as
appropriate, having added a pci_dev argument to the
ATA_{PRIM,SECOND}ARY_IRQ macros.

There's probably a better way to do this -- especially if we observe
that the _only_ case in which this seemingly-generic
"pci_get_legacy_ide_irq()" function returns anything other than 14 and
15 for primary and secondary respectively is the case of the AMD8111 on
the Maple board -- couldn't we handle that with a special case in the
pata_amd driver, or perhaps with a PCI quirk for Maple to switch it into
native mode during early boot and assign resources properly?

Signed-off-by: David Woodhouse 
Signed-off-by: Jeff Garzik

[PATCH] change WARN_ON back to "BUG: at ..."

2006-12-30T18:55:54+00:00

WARN_ON() ever triggering is a kernel bug.  Do not try to paper over this
fact by suggesting to the user that this is 'only' a warning, as the
following recent commit does:

  commit 30e25b71e725b150585e17888b130e3324f8cf7c
  Author: Jeremy Fitzhardinge 
  Date:   Fri Dec 8 02:36:24 2006 -0800

    [PATCH] Fix generic WARN_ON message

    A warning is a warning, not a BUG.

( it might make sense to rename BUG() to CRASH() and BUG_ON() to
  CRASH_ON(), but that does not change the fact that WARN_ON()
  signals a kernel bug. )

i and others objected to this change during lkml review:

  http://marc.theaimsgroup.com/?l=linux-kernel&m=116115160710533&w=2

still the change slipped upstream - grumble :)

Also, use the standard "BUG: " format to make it easier to grep logs and
to make it easier to google for kernel bugs.

Signed-off-by: Ingo Molnar 
Cc: Jeremy Fitzhardinge 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PCI: Fix multiple problems with VIA hardware

2006-12-20T18:54:43+00:00

This patch is designed to fix:
- Disk eating corruptor on KT7 after resume from RAM
- VIA IRQ handling
- VIA fixups for bus lockups after resume from RAM

The core of this is to add a table of resume fixups run at resume time.
We need to do this for a variety of boards and features, but particularly
we need to do this to get various critical VIA fixups done on resume.

The second part of the problem is to handle VIA IRQ number rules which
are a bit odd and need special handling for PIC interrupts. Various
patches broke various boxes and while this one may not be perfect
(hopefully it is) it ensures the workaround is applied to the right
devices only.

From: Jean Delvare 

Now that PCI quirks are replayed on software resume, we can safely
re-enable the Asus SMBus unhiding quirk even when software suspend support
is enabled.

[akpm@osdl.org: fix const warning]
Signed-off-by: Alan Cox 
Cc: Jean Delvare 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman