[PATCH 0/2] 2.6.5-rc2{,-mm1} i386 probe_roms() damage

[Rene Herman <rene.herman@keyaccess.nl>]

Hi Andrew,

sending this to you because, well, I guess it's sort of mm-ish. Patch is
against 2.6.5-rc2-mm1, but applies (with two offsets) to 2.6.5-rc2 as
well. Please advice if you want me to pester someone else instead.

The i386 probe_roms() function has a fair number of problems currently:

- When you actually have an adapter ROM in the machine, your video ROM
   disappears. This is due to the pc9800 subarch merge that split it up
   in probe_video_rom(int roms) and probe_extension_roms(int roms), but
   expects a "roms++" in probe_video_roms() to have an effect outside of
   that function.

- The majority of VGA adapters these days host a ROM larger then 32K,
   yet the current code hardcodes a 32K ROM. The VGA BIOS "length" byte
   is normally valid (it in fact needs to be for a regular mainboard BIOS
   to accept it) and I've verified on a few dozen very new to very old
   VGAs that it is. However, assuming someone actually did not check for
   the length and checksum there for a reason, the safe thing to do here
   is accept the length byte when we also get a valid checksum.

- The current code scans 0xc0000 to 0xdffff for a video ROM while the
   standard PC thing to do (that which the BIOS does) is only scan for a
   video ROM starting between 0xc0000 and 0xc7fff. This means that on a
   headless- (or BIOS-less monochrome adapter-) box, the first adapter
   ROM found triggers the registration of a 32K "Video ROM" at hardcoded
   address 0xc0000, even when _nothing_ is present between 0xc0000 and
   0xc7fff.

- The current adapter ROM scan stops at 0xdffff, whether or not an
   extension ROM is present at 0xe0000. The PC thing to do is scan
   0xc8000 upto 0xdffff if an extension ROM is present, and upto 0xeffff
   when it's not (it's not/hardly ever).

- Adapter ROMs are called "Extension ROM", but the latter term is really
   better reserved for a motherboard extension ROM.

- Currently, the code happily starts scanning through a ROM it just
   registered looking for the next one (just does += 2048, even when
   that's inside the previous ROM) which is at least silly.

Unfortunately, this code is "subarched" between mach-default and
mach-pc9800, meaning the patch got a bit involved. Currently all this
code, and gobs of data, is defined (not just declared) in the header:

   include/asm-i386/mach-{default,pc9800}/mach_resources.h

which isn't nice. That .h really wants to be a .c. The first patch, in
the next message, does not change any code but only undoes the
probe_video_rom / probe_extension_roms split and moves the code to a new
file

   arch/i386/mach-{default,pc9800}/std_resources.c

with a header

   include/asm-i386/std_resources.h

for the prototypes only. The second patch overhauls the code itself for
mach-default. Please see comments on top of that patch for (yet more)
comments. It's tested on various machines, with and without adapter ROMs.

I haven't touched pc9800. Nothing should have changed though. The pc9800
author, as given in the code, is CCed.

Also, x86-64 inherits the probe_roms() code from 2.4, and while it
doesn't have the subarch specific problems, it has all others. I'll
convert it to if this i386 version is deemed desirable.

Rene.