> Let me know what you think of this patch. I obviously can't test all
> drivers for weird interactions, but it seems to do the right things on
> my system, with normal drivers and with tweaked PCMCIA drivers. I
> figure we should first set up this infrastructure (and see if it
> causes any problems), then later, we can update things to populate the
> memory map.
Your changes IMHO in the right direction, but it would be better
to change the resource management code even more:
o The resource table needn't be of a constant size. A linked
list of kmalloc'ed entries fits better.
o Locking by cli/sti should be removed. Nobody needs to allocate
resources from interrupts :) It's probably enough to define
that these functions must be called with the big kernel lock held.
o There should be also a kernel option for reserving memory, not only I/O.
o Leaving traces of the previously allocated region in release_resource()
needs more thinking about -- in case you load a driver with an incorrect
base address and then unload it because it doesn't work, the region
should disappear.
o We need to handle "not free, but allow requesting" regions (typically
space known to be occupied by a card, but not allocated by a driver yet).
Maybe we should look at track occupiedness and allocatedness as two
completely different attributes. This would look this way:
check_resource() if ALLOCATED, fail
request_resource() set ALLOCATED
release_resource() reset ALLOCATED; if OCCUPIED not set, delete the region
occupy_resource() find !OCCUPIED && !ALLOCATED region
set OCCUPIED
vacate_resource() reset OCCUPIED; if not ALLOCATED, delete the region
This way we could gather information about all cards during bootup
(partly by scanning the bus as in PCI case, partly maybe by asking
the PNP BIOS -- Keith Owens was already experimenting with this),
be safe wrt. allocation of addresses for hotplug devices, but also
leave the old request/release semantics used in all the drivers intact.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "IBM = Inferior, But Marketable"- 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/