[PATCH] parport_pc superio chip fixes
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>
Showing
Please register or sign in to comment