->release() already has explicit lock_kernel() calls...
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

phone_open() looks OK, but I don't trust the subsidiary drivers (and ixj in
particular).
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

This driver would appear to have no internal locking at all.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

misc_open() looks fine, but who knows what all of the misc drivers are
doing in their open() functions?
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

It's really hard to tell if this is necessary - lots of weird
magic happens by way of map_devmem()
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Push the cdev lock_kernel() call down into the x86 msr and cpuid drivers.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Push the cdev lock_kernel() call down into the sh gio driver.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Push the cdev lock_kernel() call into MIPS-specific drivers.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Push the cdev lock_kernel() call into cris drivers.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

Push the cdev lock_kernel call into bsg_open().
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
  i2c/max6875: Really prevent 24RF08 corruption
  i2c-amd756: Fix functionality flags
  i2c: Kill the old driver matching scheme
  i2c: Convert remaining new-style drivers to use module aliasing
  i2c: Switch pasemi to the new device/driver matching scheme
  i2c: Clean up Blackfin BF527 I2C device declarations
  i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert
  i2c: New co-maintainer

Add multi_defconfig, to build a kernel for all supported m68k platforms,
excluding Sun 3 (Sun 3 kernels are incompatible with all other m68k platforms)
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Update the m68k defconfigs
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

m68k: Correctly handle multi-ISA at runtime in multi-platform kernels
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The *_ISA type defines are quite generic and cause namespace conflicts
(e.g. with `AMIGAHW_DECLARE(GG2_ISA)' in <asm/amigahw.h>) for some kernel
configurations. Use ISA_TYPE_* to avoid such conflicts.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

UIO needs m68k_mmutype:

ERROR: "m68k_mmutype" [drivers/uio/uio.ko] undefined!

(noticed by Christian T. Steigies)
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Mark Q40/Q60 floppy support broken:

    arch/m68k/q40/q40ints.c: In function 'q40_irq_handler':
    arch/m68k/q40/q40ints.c:214: error: implicit declaration of function 'floppy_hardint'

Including <asm/floppy.h> doesn't help, as it causes a lot of additional error
messages (cfr. Sun 3x).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

According to the tests in do_initcalls(), the proper error code in case no
device is found is -ENODEV, not -ENXIO or -EIO.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Some input drivers do not check whether they're actually running on the
correct platform, causing multi-platform kernels to crash if they are not.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Some network drivers do not check whether they're actually running on the
correct platform, causing multi-platform kernels to crash if they are not.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The Apollo frame buffer device driver (dnfb) doesn't check whether it's
actually running on Apollo hardware, causing a crash if it isn't.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The Macintosh IDE driver (macide) doesn't check whether it's actually running
on Mac hardware, causing a crash if it isn't.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

When running a HP300-enabled kernel on non-HP300 hardware, a test in the early
startup code jumps to the wrong label, causing a double bus fault.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>