The PNPBIOS driver and the floppy driver both fight over reservation
of the floppy port. This patch makes things friendly again.
As the comment suggests, this fix could be done better, but until
someone steps forward to fix this, this is the best we have.

copy_to_user already does the relevant checking.

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

This patch from 2.4 makes sure we don't prefetch past the
end of a range to be copied (in case its at the end of a memrange)
i386 case looks safe already, we just weren't optimal for the last
chunk to be copied.

Andi. same change needed for x86-64.

    Dave.

Syncs up with latest from Stelian

Brings up to date with the quirk in 2.4
This makes sure we only apply it on the right chipsets,
and adjusts the bits that get poked depending on which we find.

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

From 2.4

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

Adds missing checks. Probably another from William Stinson

Syncs up with Stelians latest

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

Another Sony for the apm blacklist.

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

Done by William Stinson.
Adds error handling to request_region() calls,
and converts some old check_region() calls too.

 - m68k fixes by Roman Zippel.

 - CDROM PIO mode fix by Osamu Tamita.
   (You are true "Hawk-eye" hovering over my head! Respect - and many Thanks.)

 - Virtualize the udma_enable method as well to help ARM and PPC people.  Please
   please if you would like to have some other methods virtualized in a similar
   way - just tell me or even better do it yourself at the end of ide-dma.c.
   I *don't mind* patches.

 - Fix the pmac code to adhere to the new API. It's supposed to work again.
   However this is blind coding... I give myself 80% chances for it to work ;-).

Nuke /proc/ide. For explanations why, please see the frustrated comments in the
previous change log. If one still don't see why it wasn't a good thing,
well please just take a look at the following:

Kernel size before:

    text    data     bss     dec     hex filename
1716049  403968  470252 2590269  27863d vmlinux

Kernel size after:

    text    data     bss     dec     hex filename
1680993  403488  470124 2554605  26faed vmlinux

2% of overall size! And this is not exactly an minimalistic setup.

 - Push poll_timeout down from the hwgroup to the channel. We are resetting the
   channel and not a whole hwgroup. This way using multiple pdc202xxx cards
   should magically start to work with multiple performance and resets will no
   longer lock the system.

 - Updates for PDC4030 by Peter Denison <peterd@marshadder.uklinux.net>.

 - Make ide_raw_taskfile don't care about request buffers. They where always
   NULL.

 - Port set multi mode count over from the special setting interface to
   ide_raw_taskfile. Fix errors in the corresponding interrupt handler in one go
   as well. It turned out that this is precisely the same code as in
   task_no_data_intr, so we can nuke it altogether. And finally we have found
   some problems with the set_pio_mode() command which can fail with -EBUSY -
   this is in esp. probably *very* common during boot hdparm usage those days!
   (OK it was masked by reportig too early that it finished...  Crap Crap utter
   crap it was!!!) Right now hdparm should just be extendid to properly
   sync and retry on   -EBUSY and everything should be fine.

   And now the 1 Milion EUR question for everybody who loves to put driver
   settings in to /proc:

   How the hell could echo > /proc/ide/ide0/settings blah blah blah blah handle
   properly cases like -EIO, -EBUSY and so on??? Having the possibility o do it
   does not mean that it is a good idea to use it.

   OK. After realizing the simple fact that quite a lot of low level hardware
   manipulating ioctls may require assistance in usage from proper logic which is
   *very* unlikely to be implemented in a bash (for me preferable still ksh) I
   have made my mind up.

	/proc/ide will be nuked.

 - Execute the recalibration for error recovery on precisely the same request as
   the one which failed.

 - Remove set geometry.  It's crap by means of standard specification. Because:

   1. We rely on the existence of the identify command anyway.

   2. This command was obsoleted *before* the identify command existed as far
   as I can see.

   2. I'm able to have a look at what other ATA/ATAPI drivers in the wild do:
   They don't do it.

 - Just call tuneproc in set_pio_mode() directly - we are already behind the rq
   queue there.

 - After we have uncovered the broken logics behind the whole ioctl handling we
   now just have made ide_spin_wait_hwgroup() waiting for a proper somehow
   longer timeout before giving up. This was previously just hiding the broken
   concept of setting ioctl values through /proc/ide/ideX/settings - now it just
   really helps hdparm to not to give up too early. (It shouldn't probably play
   wreck havock on the global driver spin lock as well. I will look in to this
   later.)

 - Scrap the non necessary, to say the least, disabling of interrupts for 3,
   read it again please, 3 seconds, on the local CPU inside
   ide_spin_wait_hwgroup().  Spin lock handling needs checking there badly as I
   see now as well...

Hey apparently any "special" requests are gone. We now have only
to deal with REQ_DEVICE_ACB and REQ_DEVICE_CMD. One of them is still too
much and will be killed.

This actually contains a lot of code that is never used,
as we don't currently attempt to load an inode that isn't
in cache, so the fat_get_parent is never actually reached.
However it is there (and should be right) incase some brave
soul does decide to enhance fat_get_dentry accordingly.

This patch converts reiserfs to use the new export_operations
interface for exporting a filesystem instead of the old
fh_to_dentry and dentry_to_fh.
Essentially it:

  - renamed reiserfs_dentry_to_fh to reiserfs_encode_fh
  - split reiserfs_fh_to_dentry into reiserfs_get_dentry
    and reiserfs_decode_fh
  - calls d_splice_alias from reiserfs_lookup so that building
    a dcache path from the bottom works well
  - addes reiserfs_get_parent to do a lookup of ".." without going
    through the VFS interfaces.
  - sets sb->s_export_op to be an appropriately initialised
    struct export_operations

This has been tested and works.

This patch converts ext3 to use the new export_operations for
exporting a filesystem.
In particular it
 - defines "ext3_get_parent" to do a lookup(".."),
 - calls d_splice_alias when ext3_lookup finds something,
   so that build a dcache path from the bottom up works, and
 - sets sb->s_export_op to point to an (almost empty)
   export_operations structure.  The fact that it is mostly empty
   means that the default lookup operations are used, which match the
   previous approach (i.e. use iget, and then check the generation
   number).

d_move wants the kernel to be locked, so
d_splice_alias now takes that lock.

Chris Wright <chris@wirex.com>  suggested these to limit to 80
columns and such.

1/ Return correct error code if nfs server creation fails
2/ Increase limit on number of nfsd threads

   There is no real justification for stopping a sysadmin
   from running lots and lots of nfsd threads, so we raise the
   imposed limit from 128 to 8192... maybe it should just go away...

The sunrpc/tcp layer currently allocates some resources linearly with
number of server threads.  This causes problems when there are very
small numbers of threads (e.g. lockd with one thread), so this patch
adds a small constant to the number of threads before calculating
resoures to allocate.

This patch also provide proper upper-limits for the response sizes for
lockd requests, so resources are not over-allocated.

Together these resolve problems with heavy lockd load over tcp.

 - remove page_cache_entry - I think it never ever was actually used.
 - remmove wake_up_page (as in 2.4) - never used
 - remove misleading comment ontop of pagemap.h
 - make wait_on_page* directly call wait_on_page_bit
 - some reordering and additional comments in pagemap.h

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

to {set_,clear_,}buffer_async_read).

 - Update HPT374 driver carried over from 2.4.xx series by Andrew Morton.
   Resync it with the recent host chip driver changes, or better the
   introduction of an API at all.

 - Consolidate the handling of device ID byte order in one place.
   This was spotted and patched by Bartomiej onierkiewicz.

 - Eliminate CONFIG_BLK_DEV_IDEPCI - it's duplicating the functionality of the
   already present and fine CONFIG_PCI flag and if we are a PCI host, we are
   indeed very likely to need host chip support anyway.

 - Remove some redundant info about the model and channel number from
   /proc/ide. Remove the binary entries not helpful to the user, and not used
   by any program and redundant to corresponding ioctls.

 - Properly return udma_read and udma_write values in taskfile.

 - Only initialize XXX_udma to the default handlers if it has not been
   initialized by the host chip initialization.

I have enabled spin lock debugging and can see that on device
flush the spin locks get wrong counts... no problems elsewher ethus
far. I will re check them next time around.

Transposed the last two arguments to memset, causing a slab poisoned
kernel not to use tagging correctly... Brown paper bag stuff.

Si_meminfo() is basically the same for all architectures (mips is a little
different by providing a value for the shared field that is different from
the originial intent, I will come back to this later), so it makes to have just
one instance of it: