It's repetitive and boring, and while not trivial it is usually rather
simple. The main problem is that it is hard to TEST without access to
hardware, although sometimes you can do a reasonable job even so..
The issue is mainly that the way we access IO memory space is to do:
char * iomem_base = ioremap(start, len);
and then use "read[bwl]()" and "write[bwl]()" on the ioremapped base
(plus an offset). The "ioremap()" takes a IO address space and maps it
into the kernel space so that the read/write access functions work..
What changed during 2.3.x was that earlier kernels used to accept the
read/write access functions even if he ioremap() was not done, IF the
access was to the legacy ISA region (ie if the driver only made accesses
to the 0xA0000 - 0xFFFFF range, it didn't need to ioremap).
That caused various hackish special cases, especially on non-intel
architectures where the ISA legacy region really isn't all that
special. So in 2.3.x we made the ioremap() a requirement even for old
ISA devices OR you had to use functions specifically for isa:
isa_read[bwl]()/isa_write[bwl]()/isa_memcpy_fromio()/etc
In short, the way to recognize a broken driver is to basically search
for drivers that use the non-ISA read/write functions, WITHOUT using
ioremap(). They need to be converted to either use ioremap() OR to use
the isa_ versions of the functions.
Somebody could probably write a simple shell-script with a few greps to
easily highlight "suspicious" files.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/