Stelian,

Here is a SECOND patch (called thood-pnpbiosfix-patch-20010928-2)
which applies on top of the one I previously sent (called
thood-pnpbiosvaiofix-patch-20010928-1).  It implements all the
other changes to the PnP BIOS driver that I've come up with:

-  Change typo "struct ressource" to "struct resource".
-  build_devlist() contained a memory leak: struct pci_devs were
   kmalloc()ed but not freed if left unused.  Fix.
-  Make all printk()s consistent: start messages with "PnPBIOS:"
-  Limit for-all-nodes loops to 254 iterations.
-  EXPORT set_dev_node
-  Make some code formatting and many other trivial changes
-  Incorrect nodenum was recorded in dev->devfn.  Fix.
-  But most importantly, make the driver distinguish between
   resource data that has not been set and resources that are
   reported by the PnP BIOS as extant but disabled.  Whereas
   previously a struct resource .start value of 0 was ambiguous
   between  "resource not reported" and "resource disabled",
   now use the .flags field (specifically, the IORESOURCE_UNSET bit)
   to indicate an unused struct, and use a .start value of -1
   to indicate a disabled irq or dma.  This should be backward
   compatible since unused structs .start values are initialized
   to -1.  In any case, SFAIK only the parport driver calls the
   PnP BIOS driver ATM, and I submit a patch hereafter which 
   makes it use the new semantics.

Please test this patch on your Vaio: boot with the "nobioscurrpnp"
option and get back to me.  It works fine on my ThinkPad.

Alan: In the patched driver, the devlist is built by getting all
the nodes in the boot configuration.  Obviously this is the best we
can do in the case of Vaio laptops.  For other laptops we want to
query the "current" configuration because that configuration is
the actual state of the hardware; and it can change.  It think it
might be best not to build a devlist at all. Why maintain a copy
of information which may go out of date?  Even on the Vaio we can
query the ("boot") configuration _repeatedly_ if we have to, 
without the help of a devlist.

--
Thomas