Messages in this thread | | | Date | Tue, 5 Aug 2003 08:45:33 -0700 | From | "Randy.Dunlap" <> | Subject | Re: 2.4 vs 2.6 versions of include/linux/ioport.h |
| |
On Tue, 5 Aug 2003 11:22:35 -0400 Gene Heskett <gene.heskett@verizon.net> wrote:
| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote: | >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett | <gene.heskett@verizon.net> wrote: | >| ---- | >| First, the define itself is missing in the 2.6 version. | >| | >| Many drivers seem to use this call, and in that which I'm trying | >| to build, the nforce and advansys modules use it. And while the | >| modules seem to build, they do not run properly. | >| | >| I cannot run 2.6.x for extended tests because of the advansys | >| breakage this causes. I also haven't even tried to run X because | >| of the nforce error reported when its built, the same error as | >| attacks the advansys code. | >| | >| Can I ask why this change was made, and is there a suitable | >| replacement call available that these drivers could use instead of | >| check_region(), as shown here in a snip from advansys.c? | >| ---- | >| if (check_region(iop, ASC_IOADR_GAP) != 0) { | >| ... | >| if (check_region(iop_base, ASC_IOADR_GAP) != 0) { | >| ... | >| | >| Hopeing for some hints here. | > | >check_region() was racy. Use request_region() instead. | > | > if (!request_region(iop, ASC_IOADR_GAP, "advansys")) { | > ... | > | > if (!request_region(iop_base, ASC_IOADR, "advansys")) { | > ... | > | >Of course, if successful, this assigns the region to the driver, | >while check_region() didn't do this, so release_region() should be | >used as needed to return the resources. | | Oops... I have a test compile going that changed those to | check_mem_region. And while I didn't change the i2c stuff, which | still reports the error, advansys.o built w/o error this time. | | Ok, so I can change that to !request_region, but I have NDI when to go | about releasing it, if ever, for a kernel driver thats either there, | and the hardware is used, or not because the hardware isn't present.
release_region() is already done for the normal case. It needs to be added for the error cases in advansys_detect() [wow, what a long function]. For your kernel(s) and known hardware, it may not be much of an issue. However, the in-kernel driver needs to be repaired, but it seems that not many people have the hardware...
| It seems to me that if its allocated to this driver, and capable of | being re-used at anytime, then the allocation should, once made, | stand.
Yes, request_region() should keep the region assigned until the driver is exiting (unloading). release_region() is already done in advansys_release().
| Or is my view of the world skewed and it should be done at | the bottom of whatever conditional is involved? Inquiring minds want | to know. I guess it all depends on what happens if the call is | repeated. Will it assign a new buffer each time?, thereby causeing a | memory leak, or will it find its been done once and return success | anyway?
advansys_detect() should call release_region() if it encounters errors [after it has called request_region() and returns an error].
request_region() doesn't assign buffers, it allocates IO resources, as seen in /proc/ioports or /proc/iomem. I don't know what happens on repeated calls by the same driver|module, but in general a second call will fail if the region is already allocated.
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |