The major changes implemented in this patch:
arch/i386/boot/setup.S - int13 real mode calls store results in empty_zero_page
arch/i386/kernel/setup.c - copy results from empty_zero_page to local storage
arch/i386/kernel/edd.c - module exports results via driverfs

x86 systems suffer from a disconnect between what BIOS believes is the
boot disk, and what Linux thinks BIOS thinks is the boot disk.  This
manifests itself in multi-disk systems - it's quite possible to
install a distribution, only to fail on reboot - the disk installed to
is not the disk BIOS is booting from.  Dell restricts our possible
standard factory installed Linux offerings to "disks on no more than
one controller" to avoid this problem, but mechanisms now exist to
solve it and allow such configurations.

BIOS Enhanced Disk Device Services (EDD) 3.0 provides the ability for
disk adapter BIOSs to tell the OS what it believes is the boot disk.
While this isn't widely implemented in BIOSs yet, it's time that Linux
received support to be ready as BIOSs with this feature do become
available.  At a minimum, LSI MegaRAID cards support this today.

EDD works by providing the bus (PCI, PCI-X, ISA, InfiniBand, PCI
Express, or HyperTransport) location (e.g. PCI 02:01.0) and interface
(ATAPI, ATA, SCSI, USB, 1394, FibreChannel, I2O, RAID, SATA) location
(e.g. SCSI ID 5 LUN 0) information for each BIOS int13 device.

The patch below creates CONFIG_EDD, that when defined, makes the
BIOS int13 calls to retrieve and store this information.  The data is
copied to a safe place in setup.c, and exported via driverfs.

Here's a sample driverfs tree with two BIOS int13 devices - dev 80 has
incorrect PCI bus information, thus no symlinks are made, but as much
info as possible is presented.  Dev 81 has correct PCI and SCSI
information, thus symlinks are made to the actual disc device.

/driverfs
|-- bios
|   |-- int13_dev80
|   |   |-- extensions
|   |   |-- host_bus
|   |   |-- info_flags
|   |   |-- interface
|   |   |-- raw_data
|   |   |-- sectors
|   |   `-- version
|   `-- int13_dev81
|       |-- extensions
|       |-- host_bus
|       |-- info_flags
|       |-- interface
|       |-- pci_dev -> ../../root/pci2/02:0c.0/03:00.0/04:00.0
|       |-- raw_data
|       |-- disc -> ../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0
|       |-- sectors
|       `-- version
|-- bus
|   |-- scsi
|   |   |-- devices
|   |   |   |-- 4:0:0:0 -> ../../../root/pci2/02:0c.0/03:00.0/04:00.0/scsi4/4:0:0:0
|   |   `-- drivers
|   |       `-- sd
`-- root
    |-- pci2
    |   |-- 02:0c.0
    |   |   |-- 03:00.0
    |   |   |   |-- 04:00.0
    |   |   |   |   |-- irq
    |   |   |   |   |-- name
    |   |   |   |   |-- power
    |   |   |   |   |-- resource
    |   |   |   |   `-- scsi4
    |   |   |   |       |-- 4:0:0:0
    |   |   |   |       |   |-- 4:0:0:0::p1
    |   |   |   |       |   |   |-- kdev
    |   |   |   |       |   |   |-- name
    |   |   |   |       |   |   |-- power
    |   |   |   |       |   |   `-- type
    |   |   |   |       |   |-- 4:0:0:0:disc
    |   |   |   |       |   |   |-- kdev
    |   |   |   |       |   |   |-- name
    |   |   |   |       |   |   |-- power
    |   |   |   |       |   |   `-- type
    |   |   |   |       |   |-- name
    |   |   |   |       |   |-- power
    |   |   |   |       |   `-- type


(Yes, the 'bios' top-level directory isn't the right place,
 and Patrick has promised to make something there in the future,
 at which point this can be moved.)

The 'raw_data' file contains the full set of information returned by BIOS
with extra error reporting.  This exists for vendor BIOS debugging purposes.

The 'host-bus' file contains the PCI (or ISA, HyperTransport, ...)
identifying information, as BIOS knows it.

The 'interface' file contains the SCSI (or IDE, USB, ...) identifying
information, as BIOS knows it.

The 'extensions' file lists the BIOS EDD extensions per spec.
The 'info_flags' file lists the BIOS EDD device information flags per spec.
The 'sectors' file reports the number of sectors BIOS believes this
device has.
The 'version' file lists the EDD version.  To have device path
information, this must be 0x30 or above.  Earlier EDD versions exist
without the device path - as much information as is available is presented.

At most 6 BIOS devices are reported, as that fills the space that's
left in the empty_zero_page.  In general you only care about device
80h, though for software RAID1 knowing what 81h is might be useful also.



Known issues:
- module unload leaves a directory around.  Seems related to
  creating symlinks in that directory.  Seen on kernel 2.5.41.
- refcounting of struct device objects could be improved.

TODO:
- Add IDE and USB disk device support
- when driverfs model of discs and partitions changes,
  update symlink accordingly.
- Get symlink creator helper functions exported from
  drivers/base instead of duplicating them here.
- move edd.[ch] to better locations if/when one is decided

I'd also like to acknowledge the help and comments received from Greg
KH and Patrick Mochel.  This isn't something driverfs was originally
conceived to handle, their assistance has been invaluable.

Please pull from:

BK:
    http://mdomsch.bkbits.net/linux-2.5-edd-tolinus

Patch (against 2.5.41+BK-current):
    http://domsch.com/linux/edd30/edd-driverfs-6.patch
    http://domsch.com/linux/edd30/edd-driverfs-6.patch.sign

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Noticed by Peter Chubb.

SCpnt->sense_buffer[0] has to _equal_ 0xf0 for the sense to be valid,
not vice versa.

Make 64-bit sector_t compulsory.  Accelerated testing...

From Peter Chubb

The bios geometry is almost useless, except for fdisk to try to write
an MSDOS partition table that is vaguely compatible with one written by
other operating systems.

If the size of disc will overflow a ten-bit cylinder number, then all
bets are off anyway.  So fake it by casting the true disc capacity to a
smaller type (than u64), so that we avoid 64-bit division on 32-bit
platforms.  If the disc is small enough that the number of cylinders is
correct, then this has no effect; otherwise, the number-of-cylinders we
report is bogus, but you can't use an MSDOS-format partition table on
such a drive anyway --- use the EFI GPT or the LDM partitioning, which
use 64-bit offsets internally.

From Peter Chubb

Get rid of need for GCC _udivdi3 and _umoddi3 helper functions
 - use sector_div more aggressively.

From Peter Chubb

(Yes I forgot something...  Without this patch, trying to use RAID
without CONFIG_LBD would fail.)

Fix md operation without CONFIG_LBD --- don't try to include __udivdi3
etc.

From Peter Chubb

Filesystem migration to possibly 64-bit sector_t:
 - bmap() now takes and returns a sector_t to allow filesystems
   (e.g., JFS, XFS) that are 64-bit clean to deal with large files
 - buffer handling now 64-bit clean

Enable 64-bit sector_t on IA32 and PPC.

kiobufs takes sector_t array, not array of long.
Fix blkmtd.c to deal in such an array.

Miscellaneous fixes for 64-bit sector_t.
 	 - missed printk formats
	 - ide_floppy_do_request had incorrect signature
	 - in blkmtd.c there was a pointer used to
	   manipulate an array to be used by kiobuf --
 	   it was unsigned long, needed to be sector_t

From Peter Chubb

Compaq Smart array sector_t cleanup: prepare for possible 64-bit sector_t

Clean up loop device to allow huge backing files.

MD transition to 64-bit sector_t.
 - Hold sizes and offsets as sector_t not int;
 - use 64-bit arithmetic if necessary to map block-in-raid to zone
   and block-in-zone

From Peter Chubb

printk changes: A sector_t can be either 64 or 32 bits, so cast it to a
printable type that is at least as large as 64-bits on all platforms
(i.e., cast to unsigned long long and use a %llu format)

Transition to 64-bit sector_t: fix isofs_get_blocks by converting the
(possibly 64-bit) arg to a long.

SCSI 64-bit sector_t cleanup: capacity now stored as sector_t; make
sure that the READ_CAPACITY command doesn't sign-extend its returned
value; avoid 64-bit division when printing size in MB.

Still to do:
 - 16-byte SCSI commands
 - Individual scsi drivers.

peter's code works for me, and the 40-odd people who download
the -mm patches.  Anton has tested it on ppc64 and I presume that
Peter has tested it on ia64.  I use gcc-2.91.66 and others use
later compilers.  I expect that any remaining problems will
mainly be caught by the compiler.  And compiler bugs can be
detected by turning off the option in config and seeing if things
get better.

From Peter Chubb

 - do_request() function takes sector_t not unsigned long as the
   block number to operate on.
 - Various casts to long where the underlying device can never get
   big enough to warrant a 64-bit sector offset.
 - Cast sector_t to unsigned long long when printing.

into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-core

scsi_syms.c:
  Missing export
drivers/scsi/aic7xxx_old.c:
   More updates for the slave_attach stuff
drivers/scsi/scsi_scan.c:
   Make scsi_scan.c call hostt->slave_attach after we have set the
   sdev->tagged_supported variable

device_unregister() is intended to be the complement of device_register(), and assumes
most of the functionality of the current put_device(). It should be called by the bus 
driver when a device is physically removed from the system. 

It should _not_ be called from a driver's remove() method, as that remove() method is called
via device_detach() in device_unregister(). 

dev->present is used to flag the physical presence of the device. It is set when the device
is registered, and cleared when unregistered. get_device() checks this flag, and returns
a NULL pointer if cleared. This prevents anyone from obtaining a reference to a device
that has been unregistered (removed), but not yet been freed (e.g. if someone else is 
holding a reference to it).

put_device() BUG()s if dev->present is set. A device should be unregistered before it is 
freed. This will catch people doing it in the wrong order. 

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

This fixes some critical bugs in cpqarray in 2.5.  One of the fixes
essentially backs out the block queue stop/start behavior that was added
recently.  This code as it stands is buggy and locks up under even light
SMP workloads.  Certainly we want the performance benefits of proper
block queue plugging, but the driver needs some work before it will fit
nicely.

Some of these fixes do theoretically hurt performance, but when you
consider that the driver is unusable under SMP as-is, I think it is
right to get correctness first.

Specifically, this patch does the following:

* Adds locking to proc queue-walking code for debugging use.  Note that
  the proc registration is still broken and I've left it that way since
  this stuff should probably migrate to driverfs anyway.

* Moves interrupt enabling so queue lock is initialized before
  interrupts are enabled.  Otherwise if we get a quick interrupt we oops
  the machine.

* Removes unconditional IRQ enabling in do_ida_request().  The block
  layer takes the spinlock with irq_save so if we're going to play this
  trick then we need to irq_restore.  For now, just eliminate the
  unlocked region.

* Remove block queue stop/start logic since it can leave the queue
  stopped with no outstanding completions to start it again.  Plugging
  logic can come back but it should go hand-in-hand with a cleanup of
  the driver's request handling algorithm.  If nobody screams about this
  patch I'll go ahead and start making those improvments.

This last patch removes the union, replacing it with s_fs_info.

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

Ingo chamged it again 8)