Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: Ok, making ready for pre-2.4 and code-freeze.. | Date | 14 Dec 1999 23:19:40 -0800 |
| |
In article <Pine.LNX.4.05.9912150433270.24762-100000@ns.snowman.net>, Stephen Frost <sfrost@ns.snowman.net> wrote: > > What kind of work is this? If it's pretty simple stuff, just repetitive, >I may be able to help out. Got an example of before/after? Or at least let me >know of a driver that has been 'properly' updated so I have something to work >from? I'll try and look at some of the code, I'm pretty good at C, but not too >terribly familiar w/ kernel internals (yet. :) ).
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/
| |