While in search of a different bug, I found this one
that got in with the recent 'async_next' patch.  The
schedule scan termination changed (had to), but it
wasn't quite correct.  Slower and/or misbehaving
devices might have wedged a CPU ... fix is simple,
only restart the scan when the list may have changed.

Thanks to Troy Benjegerdes and Jason Carnahan for first cuts at this...

Here's a trivial patch for the file to switch it to use C99
initializers. The patch is against 2.5.50.

Here are patches for switching two files over to use C99 initializers.
The patches are against 2.5.50.

Here's  small patch for the file fixing a few initializers to use C99
style. The patch is against 2.5.50.

Here's a patch for switching the file to use C99 initializers. The patch
is against 2.5.50.

  This patch fixes stupid cut+paste bug in dsbr100.

This contains three changes.  The first removes some #defines that don't
seem to be needed anymore.  The second fixes a problem when CONFIG_LBD
is set and sector_t is u64.  The third fixes some compile warnings
setting a char * in the scsi_pointer struct to a dma_addr_t.  I changed
the usage from the ptr element to the dma_handle element.

It compiles without warnings and I have run some tests on aacraid devices
on the osdl lab machines with the CONFIG_LBD option on and off.

This simplifies logic in acpi_wakeup.S by putting code and data into
same segment. Plus it kills off-by-3 bug and uses constant instead of
hardcoded value.

When kernel becomes too big, table allocated in acpi.c is no longer
big enough and machine crashes during acpi_wakeup.S... This fixes
it and adds safety check for acpi_wakeup's code size.

This adds basic support to md.c.

This makes swsusp 64bit compatible, and makes it work in case of two
mirrors of physical memory (x86-64 works like that). It also contains
few accumulated cleanups.

swsusp: Move loop variables into assembly, where they are used.

This moves CONFIG_SOFTWARE_SUSPEND where it belongs, and makes
ACPI_SLEEP depend on it to prevent compile problems.

From:  Chris Wilson <chris@qwirx.com>

  If the call to devfs_register() fails, then the driver does not deregister
  its misc device before returning an error. This should fix it.

From:  william stinson <wstinson@wanadoo.fr>

  	1) removes one call to check_region
  	2) uses request_region instead
  	3) calls release_region in case of driver initialisation error later on

From:  Michael Still <mikal@stillhq.com>

[ Return error from misc_register-002-002, not some random value ]
From:  Michael Still <mikal@stillhq.com>

From:  Paul <set@pobox.com>

From:  Brad Hards <bhards@bigpond.net.au>

From:  Stephen Rothwell <sfr@canb.auug.org.au>

  Every definition if sigmask() was the same.  In one case it was
  mutilply defined for the arm architecture.  This patch removes all the
  architecture defines of sigmask and moves the generic define from
  the protection of __HAVE_ARCH_SIG_BITOPS.

From:  Greg Ungerer <gerg@moreton.com.au>

From:  Brad Hards <bhards@bigpond.net.au>

From:  Marcus Alanen <maalanen@ra.abo.fi>

  The freeall label already does the kfree(dev->priv)

From:  Greg Ungerer <gerg@moreton.com.au>

  Put in missing Makefile var bracket in 68328 processor support.

From:  Marcus Alanen <maalanen@ra.abo.fi>

  On error we don't release the previously allocated struct mii_phy:s

From:  Greg Ungerer <gerg@moreton.com.au>

From:  Michael Still <mikal@stillhq.com>

From:  Ryan Bradetich <rbradetich@uswest.net>

From:  Brad Hards <bhards@bigpond.net.au>

From:  Brad Hards <bhards@bigpond.net.au>

From:  Marcus Alanen <maalanen@ra.abo.fi>

  As far as I can see, setup_arg_pages code is hosed for the
  ARCH_STACK_GROWSUP case, completely wrong types...

  Does any arch even use this?

From:  Greg Ungerer <gerg@moreton.com.au>

  Add the new kernel_stat struct offset to the audo-generated offsets
  for arch/m68knommu/kernel/asm-offsets.c.

From:  Gerd Knorr <kraxel@bytesex.org>

  This adds the missing video-buf.o module to the module list if
  CONFIG_VIDEO_SAA7134 is enabled.

From:  Gerd Knorr <kraxel@bytesex.org>

From:  Michael Still <mikal@stillhq.com>