This patch fixes some troubles that somebody reported me with the superio
chips.

In short rmmod parport_pc && cat /proc/iomem was good enough for crashing
the box hard on some machine (and hwscan --printer was doing just that).
The way the oops triggers is that iomem tries to vsprintf the p->name, but
the p->name was a static string in the module address (now unloaded).

The reason is that the superio chip scanning leaves up to two persistent
ranges claimed.  But the second (legacy) pass has no way to notice the
resources are already reclaimed.  Plus if the superio->io was different
than the "io" variable (the range to scan for superio chips) the "io" range
would generate a leak of the original "io" range too.

I simply make sure to always release the requested space during the superio
scan, and I make sure not to istantiate new ranges in the p->base that
would cause the later parport scan to fail too (plus leaving up to leaked
resources).

The previous code that was returning values and was leaving garbage in
there made no sense to me.  My best guess (assuming I didn't misread it ;)
is that probably somebody added the request_region without realizing
they're pointing to the very same address that would be requested later
(and nobody does accesses on those ranges until later, so it was very safe
to claim it later).

Disclaimer: I don't have the specs of the winbond and smsc at hand, I just
guessed what they do from the code (nothing checks superio->io except
get_superio_dma get_superio_irq, which made the thing enough self
explainatory to fix it without specs)
Signed-off-by: Andrea Arcangeli <andrea@novell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>