[PATCH 2.4] (0/5) I2C updates for 2.4.32-pre3

[PATCH 2.4] (0/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Hi Marcelo,

I have a total of 5 patches with minor fixes to the Linux 2.4 i2c
subsystem and documentation. These fixes I gathered for the past few
months as they were applied to the Linux 2.6 tree and to the i2c CVS
repository.

Individual patches will be posted in reply to this post, with
explanations and diffstat. Please consider applying them.

Thanks.

 Documentation/i2c/dev-interface   |    4 ++--
 Documentation/i2c/functionality   |    2 +-
 Documentation/i2c/writing-clients |    2 +-
 MAINTAINERS                       |    2 +-
 drivers/i2c/i2c-core.c            |   10 +++++-----
 drivers/i2c/i2c-dev.c             |    2 +-
 6 files changed, 11 insertions(+), 11 deletions(-)

-- 
Jean Delvare

[PATCH 2.4] (1/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Backport of a spelling fix Tobias Klauser sent to me for Linux
2.6.12-rc4. Already fixed in i2c CVS.

Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

 drivers/i2c/i2c-dev.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2.4.30.orig/drivers/i2c/i2c-dev.c	2005-06-03 19:21:12.000000000 +0200
+++ linux-2.4.30/drivers/i2c/i2c-dev.c	2005-06-03 19:22:52.000000000 +0200
@@ -229,7 +229,7 @@
 				   sizeof(rdwr_arg)))
 			return -EFAULT;
 
-		/* Put an arbritrary limit on the number of messages that can
+		/* Put an arbitrary limit on the number of messages that can
 		 * be sent at once */
 		if (rdwr_arg.nmsgs > 42)
 			return -EINVAL;

-- 
Jean Delvare

Re: [PATCH 2.4] (0/5) I2C updates for 2.4.32-pre3

[Michael Krufky]

Jean Delvare wrote:

>I have a total of 5 patches with minor fixes to the Linux 2.4 i2c
>subsystem and documentation. These fixes I gathered for the past few
>months as they were applied to the Linux 2.6 tree and to the i2c CVS
>repository.
>
>Individual patches will be posted in reply to this post, with
>explanations and diffstat. Please consider applying them.
>  
>
How come these patches never showed up on LKML?

-- 
Michael Krufky

Re: [PATCH 2.4] (0/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Hi Michael,

> > Individual patches will be posted in reply to this post, with
> > explanations and diffstat. Please consider applying them.
>
> How come these patches never showed up on LKML?

They did, just with some delay. I'm only a human.

-- 
Jean Delvare

[PATCH 2.4] (2/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

The lm_sensors project changed mailing lists.

Signed-off-by: Jean Delvare <khali@linux-fr.org>

 MAINTAINERS |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-2.4.30.orig/MAINTAINERS	2005-06-03 19:21:41.000000000 +0200
+++ linux-2.4.30/MAINTAINERS	2005-06-03 19:23:35.000000000 +0200
@@ -820,7 +820,7 @@
 I2C SUBSYSTEM
 P:	Jean Delvare
 M:	khali@linux-fr.org
-L:	sensors@stimpy.netroedge.com
+L:	lm-sensors@lm-sensors.org
 W:	http://www.lm-sensors.nu/
 S:	Maintained
 

-- 
Jean Delvare

[PATCH 2.4] (3/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Fix documentation to match code in include/linux/i2c-dev.h

Signed-off-by: Jan Veldeman <jan@mind.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>

 Documentation/i2c/dev-interface |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.4.31.orig/Documentation/i2c/dev-interface	2004-02-18 14:36:30.000000000 +0100
+++ linux-2.4.31/Documentation/i2c/dev-interface	2005-07-13 23:27:06.000000000 +0200
@@ -92,10 +92,10 @@
 ioctl(file,I2C_FUNCS,unsigned long *funcs)
   Gets the adapter functionality and puts it in *funcs.
 
-ioctl(file,I2C_RDWR,struct i2c_ioctl_rdwr_data *msgset)
+ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
 
   Do combined read/write transaction without stop in between.
-  The argument is a pointer to a struct i2c_ioctl_rdwr_data {
+  The argument is a pointer to a struct i2c_rdwr_ioctl_data {
 
       struct i2c_msg *msgs;  /* ptr to array of simple messages */
       int nmsgs;             /* number of messages to exchange */

-- 
Jean Delvare

[PATCH 2.4] (4/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Fix two typos in the i2c documentation.

Signed-off-by: Jean Delvare <khali@linux-fr.org>

 Documentation/i2c/functionality   |    2 +-
 Documentation/i2c/writing-clients |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.4.31.orig/Documentation/i2c/functionality	2000-12-29 23:35:47.000000000 +0100
+++ linux-2.4.31/Documentation/i2c/functionality	2005-07-28 19:06:36.000000000 +0200
@@ -115,7 +115,7 @@
 If you try to access an adapter from a userspace program, you will have
 to use the /dev interface. You will still have to check whether the
 functionality you need is supported, of course. This is done using
-the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2c_detect
+the I2C_FUNCS ioctl. An example, adapted from the lm_sensors i2cdetect
 program, is below:
 
   int file;
--- linux-2.4.31.orig/Documentation/i2c/writing-clients	2005-04-09 12:14:20.000000000 +0200
+++ linux-2.4.31/Documentation/i2c/writing-clients	2005-07-29 19:32:57.000000000 +0200
@@ -302,7 +302,7 @@
      These are automatically translated to insmod variables of the form
      force_foo.
 
-So we have a generic insmod variabled `force', and chip-specific variables
+So we have a generic insmod variable `force', and chip-specific variables
 `force_CHIPNAME'.
 
 Fortunately, as a module writer, you just have to define the `normal' 

-- 
Jean Delvare

[PATCH 2.4] (5/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Five log messages lack their trailing new line in i2c-core.

Signed-off-by: Jean Delvare <khali@linux-fr.org>

 drivers/i2c/i2c-core.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

--- linux-2.4.31.orig/drivers/i2c/i2c-core.c	2005-04-09 12:35:59.000000000 +0200
+++ linux-2.4.31/drivers/i2c/i2c-core.c	2005-07-28 19:29:25.000000000 +0200
@@ -208,7 +208,7 @@
 			if ((res = drivers[j]->attach_adapter(adap))) {
 				printk(KERN_WARNING "i2c-core.o: can't detach adapter %s "
 				       "while detaching driver %s: driver not "
-				       "detached!",adap->name,drivers[j]->name);
+				       "detached!\n", adap->name, drivers[j]->name);
 				goto ERROR1;	
 			}
 	DRV_UNLOCK();
@@ -226,7 +226,7 @@
 			if ((res=client->driver->detach_client(client))) {
 				printk(KERN_ERR "i2c-core.o: adapter %s not "
 					"unregistered, because client at "
-					"address %02x can't be detached. ",
+					"address %02x can't be detached\n",
 					adap->name, client->addr);
 				goto ERROR0;
 			}
@@ -339,7 +339,7 @@
 				printk(KERN_WARNING "i2c-core.o: while unregistering "
 				       "dummy driver %s, adapter %s could "
 				       "not be detached properly; driver "
-				       "not unloaded!",driver->name,
+				       "not unloaded!\n", driver->name,
 				       adap->name);
 				ADAP_UNLOCK();
 				return res;
@@ -361,7 +361,7 @@
 						       "address %02x of "
 						       "adapter `%s' could not"
 						       "be detached; driver"
-						       "not unloaded!",
+						       "not unloaded!\n",
 						       driver->name,
 						       client->addr,
 						       adap->name);
@@ -448,7 +448,7 @@
 	if (adapter->client_unregister != NULL) 
 		if ((res = adapter->client_unregister(client))) {
 			printk(KERN_ERR "i2c-core.o: client_unregister [%s] failed, "
-			       "client not detached",client->name);
+			       "client not detached\n", client->name);
 			return res;
 		}
 

-- 
Jean Delvare

Re: [PATCH 2.4] (5/5) I2C updates for 2.4.32-pre3

[Marcelo Tosatti]

On Sun, Aug 14, 2005 at 05:17:16PM +0200, Jean Delvare wrote:
> Five log messages lack their trailing new line in i2c-core.

Jean,

All of these seem to be cleanups/cosmetic enhancements rather than real 
bugfixes, except the ML address update.

As you know, we've been trying to reduce the scope of patch acceptance
in v2.4.x to strictly necessary changes. 

Do any of these fall into this criteria? 

Cheers.

Re: [PATCH 2.4] (5/5) I2C updates for 2.4.32-pre3

[Jean Delvare]

Hi Marcelo,

> All of these seem to be cleanups/cosmetic enhancements rather than
> real bugfixes, except the ML address update.

Patches 1/5, 3/5 and 4/5 are typo fixes in documentation and comments.
5/5 however qualifies as (minor) bug fix IMHO, as missing newlines in
log messages will cause the next message's log level not to be
interpreted as such.

> As you know, we've been trying to reduce the scope of patch acceptance
> in v2.4.x to strictly necessary changes. 
> 
> Do any of these fall into this criteria? 

I sent you these patches because I thought they were worth applying,
obviously, so don't ask me. Apply them or discard them as you feel like,
it's really up to you, not me. From that, I'll know what kind of patches
are worth sending next time.

Thanks,
-- 
Jean Delvare