All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, sensors@stimpy.netroedge.com
Subject: [PATCH] i2c driver fixes for 2.6.0-test5
Date: Thu, 19 May 2005 06:24:19 +0000	[thread overview]
Message-ID: <20030923190440.GA5205@kroah.com> (raw)
In-Reply-To: <20030923172258.B19880@infradead.org>

On Tue, Sep 23, 2003 at 05:22:58PM +0100, Christoph Hellwig wrote:
> On Tue, Sep 23, 2003 at 09:19:29AM -0700, Greg KH wrote:
> > Ok, from my reading of this horrible chunk of code it does the
> > following:
> > 	- if this is a isa based controller, then we check the region
> > 	  that is to be used.
> > 	- If it is already in use by someone else, then we skip it, and
> > 	  move on to the next address.
> > 	- If it is not in use, then we pass the address down to the chip
> > 	  driver and let it try to find the chip at this address (it
> > 	  will do the reserving of the address space on its own.)
> > 
> > So basically, check_region is pretty valid here, as we are trying to see
> > if something else is already at this address, to try to prevent i2c
> > drivers from stomping on each other.  I replaced this with a
> > request_region()/release_region() pair to get rid of the compiler
> > warning.
> > 
> > Is this your understanding too?  Or do you think we should just get rid
> > of the request_region() check here all together?
> 
> Yes, either we should get rid of it or move claiming the address to
> the i2c midlayer (not sure whether that's a good idea).  But an
> opencoded check_region doesn't make any more sense than an explicit
> one.  And you're also looking at the pointer it returned after it's
> already invalid again..

Heh, good point.  Ok, I dug out a box that uses a isa i2c adapter and
tested the patch below.  As the chip drivers are using request_region
properly, taking this check out of i2c-sensor.c makes sense.

thanks,

greg k-h


diff -Nru a/drivers/i2c/i2c-sensor.c b/drivers/i2c/i2c-sensor.c
--- a/drivers/i2c/i2c-sensor.c	Tue Sep 23 12:03:13 2003
+++ b/drivers/i2c/i2c-sensor.c	Tue Sep 23 12:03:13 2003
@@ -50,10 +50,7 @@
 		return -1;
 
 	for (addr = 0x00; addr <= (is_isa ? 0xffff : 0x7f); addr++) {
-		void *region_used = request_region(addr, 1, "foo");
-		release_region(addr, 1);
-		if ((is_isa && (region_used = NULL)) ||
-		    (!is_isa && i2c_check_addr(adapter, addr)))
+		if (!is_isa && i2c_check_addr(adapter, addr))
 			continue;
 
 		/* If it is in one of the force entries, we don't do any

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, sensors@stimpy.netroedge.com
Subject: Re: [PATCH] i2c driver fixes for 2.6.0-test5
Date: Tue, 23 Sep 2003 12:04:40 -0700	[thread overview]
Message-ID: <20030923190440.GA5205@kroah.com> (raw)
In-Reply-To: <20030923172258.B19880@infradead.org>

On Tue, Sep 23, 2003 at 05:22:58PM +0100, Christoph Hellwig wrote:
> On Tue, Sep 23, 2003 at 09:19:29AM -0700, Greg KH wrote:
> > Ok, from my reading of this horrible chunk of code it does the
> > following:
> > 	- if this is a isa based controller, then we check the region
> > 	  that is to be used.
> > 	- If it is already in use by someone else, then we skip it, and
> > 	  move on to the next address.
> > 	- If it is not in use, then we pass the address down to the chip
> > 	  driver and let it try to find the chip at this address (it
> > 	  will do the reserving of the address space on its own.)
> > 
> > So basically, check_region is pretty valid here, as we are trying to see
> > if something else is already at this address, to try to prevent i2c
> > drivers from stomping on each other.  I replaced this with a
> > request_region()/release_region() pair to get rid of the compiler
> > warning.
> > 
> > Is this your understanding too?  Or do you think we should just get rid
> > of the request_region() check here all together?
> 
> Yes, either we should get rid of it or move claiming the address to
> the i2c midlayer (not sure whether that's a good idea).  But an
> opencoded check_region doesn't make any more sense than an explicit
> one.  And you're also looking at the pointer it returned after it's
> already invalid again..

Heh, good point.  Ok, I dug out a box that uses a isa i2c adapter and
tested the patch below.  As the chip drivers are using request_region
properly, taking this check out of i2c-sensor.c makes sense.

thanks,

greg k-h


diff -Nru a/drivers/i2c/i2c-sensor.c b/drivers/i2c/i2c-sensor.c
--- a/drivers/i2c/i2c-sensor.c	Tue Sep 23 12:03:13 2003
+++ b/drivers/i2c/i2c-sensor.c	Tue Sep 23 12:03:13 2003
@@ -50,10 +50,7 @@
 		return -1;
 
 	for (addr = 0x00; addr <= (is_isa ? 0xffff : 0x7f); addr++) {
-		void *region_used = request_region(addr, 1, "foo");
-		release_region(addr, 1);
-		if ((is_isa && (region_used == NULL)) ||
-		    (!is_isa && i2c_check_addr(adapter, addr)))
+		if (!is_isa && i2c_check_addr(adapter, addr))
 			continue;
 
 		/* If it is in one of the force entries, we don't do any

  reply	other threads:[~2005-05-19  6:24 UTC|newest]

Thread overview: 125+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-22 23:28 [BK PATCH] i2c driver fixes for 2.6.0-test5 Greg KH
2005-05-19  6:24 ` Greg KH
2003-09-22 23:30 ` [PATCH] " Greg KH
2005-05-19  6:24   ` Greg KH
2003-09-22 23:30   ` Greg KH
2005-05-19  6:24     ` Greg KH
2003-09-22 23:30     ` Greg KH
2005-05-19  6:24       ` Greg KH
2003-09-22 23:30       ` Greg KH
2005-05-19  6:24         ` Greg KH
2003-09-22 23:30         ` Greg KH
2005-05-19  6:24           ` Greg KH
2003-09-22 23:30           ` Greg KH
2005-05-19  6:24             ` Greg KH
2003-09-22 23:30             ` Greg KH
2005-05-19  6:24               ` Greg KH
2003-09-22 23:30               ` Greg KH
2005-05-19  6:24                 ` Greg KH
2003-09-22 23:30                 ` Greg KH
2005-05-19  6:24                   ` Greg KH
2003-09-22 23:30                   ` Greg KH
2005-05-19  6:24                     ` Greg KH
2003-09-22 23:30                     ` Greg KH
2005-05-19  6:24                       ` Greg KH
2003-09-22 23:30                       ` Greg KH
2005-05-19  6:24                         ` Greg KH
2003-09-22 23:30                         ` Greg KH
2005-05-19  6:24                           ` Greg KH
2003-09-22 23:30                           ` Greg KH
2005-05-19  6:24                             ` Greg KH
2003-09-22 23:30                             ` Greg KH
2005-05-19  6:24                               ` Greg KH
2003-09-22 23:30                               ` Greg KH
2005-05-19  6:24                                 ` Greg KH
2003-09-22 23:30                                 ` Greg KH
2005-05-19  6:24                                   ` Greg KH
2003-09-22 23:30                                   ` Greg KH
2005-05-19  6:24                                     ` Greg KH
2003-09-22 23:30                                     ` Greg KH
2005-05-19  6:24                                       ` Greg KH
2003-09-22 23:30                                       ` Greg KH
2005-05-19  6:24                                         ` Greg KH
2003-09-22 23:30                                         ` Greg KH
2005-05-19  6:24                                           ` Greg KH
2003-09-22 23:30                                           ` Greg KH
2005-05-19  6:24                                             ` Greg KH
2003-09-22 23:30                                             ` Greg KH
2005-05-19  6:24                                               ` Greg KH
2003-09-22 23:30                                               ` Greg KH
2005-05-19  6:24                                                 ` Greg KH
2003-09-22 23:30                                                 ` Greg KH
2005-05-19  6:24                                                   ` Greg KH
2003-09-22 23:30                                                   ` Greg KH
2005-05-19  6:24                                                     ` Greg KH
2003-09-22 23:30                                                     ` Greg KH
2005-05-19  6:24                                                       ` Greg KH
2003-09-22 23:30                                                       ` Greg KH
2005-05-19  6:24                                                         ` Greg KH
2003-09-22 23:30                                                         ` Greg KH
2005-05-19  6:24                                                           ` Greg KH
2005-05-19  6:24     ` Greg KH
2003-09-22 23:30       ` Greg KH
2005-05-19  6:24         ` Greg KH
2003-09-22 23:30         ` Greg KH
2005-05-19  6:24           ` Greg KH
2003-09-22 23:30           ` Greg KH
2005-05-19  6:24             ` Greg KH
2003-09-23  8:16         ` Christoph Hellwig
2005-05-19  6:24           ` Christoph Hellwig
2003-09-23 16:19           ` Greg KH
2005-05-19  6:24             ` Greg KH
2003-09-23 16:22             ` Christoph Hellwig
2005-05-19  6:24               ` Christoph Hellwig
2003-09-23 19:04               ` Greg KH [this message]
2005-05-19  6:24                 ` Greg KH
2003-09-23 19:08                 ` Christoph Hellwig
2005-05-19  6:24                   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2003-10-10 23:10 [BK PATCH] i2c driver fixes for 2.6.0-test7 Greg KH
2005-05-19  6:24 ` Greg KH
2003-10-10 23:11 ` [PATCH] " Greg KH
2005-05-19  6:24   ` Greg KH
2003-10-10 23:11   ` Greg KH
2005-05-19  6:24     ` Greg KH
2003-10-10 23:11     ` Greg KH
2005-05-19  6:24       ` Greg KH
2003-10-10 23:11       ` Greg KH
2005-05-19  6:24         ` Greg KH
2003-08-15 18:32 [BK PATCH] i2c driver fixes for 2.6.0-test3 Greg KH
2005-05-19  6:24 ` Greg KH
2003-08-15 18:33 ` [PATCH] i2c driver changes 2.6.0-test3 Greg KH
2005-05-19  6:24   ` Greg KH
2003-08-15 18:33   ` Greg KH
2005-05-19  6:24     ` Greg KH
2003-08-15 18:33     ` Greg KH
2005-05-19  6:24       ` Greg KH
2003-08-15 18:33       ` Greg KH
2005-05-19  6:24         ` Greg KH
2003-08-15 18:33         ` Greg KH
2005-05-19  6:24           ` Greg KH
2003-08-15 18:33           ` Greg KH
2005-05-19  6:24             ` Greg KH
2003-08-15 18:33             ` Greg KH
2005-05-19  6:24               ` Greg KH
2003-08-15 18:33               ` Greg KH
2005-05-19  6:24                 ` Greg KH
2005-05-19  6:24     ` Philip Pokorny
2005-05-19  6:24     ` Jean Delvare
2005-05-19  6:24     ` Mark D. Studebaker 
2005-05-19  6:24     ` Jean Delvare
2005-05-19  6:24     ` Greg KH
2003-08-02  5:29 [BK PATCH] i2c driver fixes for 2.6.0-test2 Greg KH
2005-05-19  6:24 ` Greg KH
2005-05-19  6:24 ` Greg KH
2005-05-19  6:24 ` Mark M. Hoffman
2005-05-19  6:24 ` Jean Delvare
2005-05-19  6:24 ` Mark M. Hoffman
2003-08-14  5:13   ` Mark M. Hoffman
2005-05-19  6:24     ` Mark M. Hoffman
2003-08-14 21:14     ` Greg KH
2005-05-19  6:24       ` Greg KH
2005-05-19  6:24 ` Greg KH
2005-05-19  6:24 ` [BK PATCH] i2c driver fixes for 2.6.0-test5 Greg KH
2005-05-19  6:24 ` Mark M. Hoffman
2005-05-19  6:24 ` Mark M. Hoffman
2005-05-19  6:24 ` Jean Delvare

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=20030923190440.GA5205@kroah.com \
    --to=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sensors@stimpy.netroedge.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.