linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: gene.heskett@verizon.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4 vs 2.6 versions of include/linux/ioport.h
Date: Tue, 5 Aug 2003 08:45:33 -0700	[thread overview]
Message-ID: <20030805084533.3b0fd474.rddunlap@osdl.org> (raw)
In-Reply-To: <200308051122.35712.gene.heskett@verizon.net>

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

  reply	other threads:[~2003-08-05 15:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-05 14:41 2.4 vs 2.6 versions of include/linux/ioport.h Gene Heskett
2003-08-05 14:57 ` Randy.Dunlap
2003-08-05 15:22   ` Gene Heskett
2003-08-05 15:45     ` Randy.Dunlap [this message]
2003-08-05 19:08       ` Gene Heskett
2003-08-05 22:07         ` 2.4 vs 2.6 ver# extra configure info CONFIGURE_ARGS += --disable-debug --enable-final --with-java=/usr/java/j2re1.4.1sions " Gene Heskett
2003-08-06  0:26           ` Andrew McGregor
2003-08-06  1:56             ` 2.4 vs 2.6 versions " Gene Heskett
2003-08-06  2:08           ` 2.5/2.6 NVidia (was Re: 2.4 vs 2.6 ver# Valdis.Kletnieks
2003-08-06  2:32             ` Gene Heskett
2003-08-06  2:53             ` Gene Heskett
2003-08-06  3:06               ` Valdis.Kletnieks
2003-08-06  5:51                 ` 2.5/2.6 NVidia (was Re: 2.4 vs 2.6 version of ioport.h) Gene Heskett
2003-08-06  0:50   ` 2.4 vs 2.6 versions of include/linux/ioport.h Gene Heskett
2003-08-05 15:10 ` Gene Heskett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030805084533.3b0fd474.rddunlap@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=gene.heskett@verizon.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).