linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 2.4] i2c cleanups, third wave
@ 2004-01-11 13:42 Jean Delvare
  2004-01-11 13:51 ` [PATCH 2.4] i2c cleanups, third wave (1/8) Jean Delvare
                   ` (9 more replies)
  0 siblings, 10 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 13:42 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

I will be sending 8 patches to you, based on linux-2.4.25-pre4. They
contain cleanups for the i2c subsystem code, ported from LM Sensors' i2c
CVS repository [1]. Since that repository was also the base of the i2c
subsystem as is now in linux 2.6, one might also consider these patches
as backports from linux 2.6.

Details about what the patch does and credits will be found with each
patch.

Please apply,
thanks.

[1] http://www2.lm-sensors.nu/~lm78/cvs/browse.cgi/i2c

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (1/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
@ 2004-01-11 13:51 ` Jean Delvare
  2004-01-11 13:59 ` [PATCH 2.4] i2c cleanups, third wave (2/8) Jean Delvare
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 13:51 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

This patch fixes a few errors in drivers/i2c/Config.in:
* missing dependancy
* empty line, indentation, typo

The thin part of this patch that also applies to linux 2.6 has been sent
to Greg KH.


--- linux-2.4.24-pre3/drivers/i2c/Config.in.orig	Wed Dec 31 17:22:11 2003
+++ linux-2.4.24-pre3/drivers/i2c/Config.in	Sun Jan  4 20:00:59 2004
@@ -7,7 +7,6 @@
 tristate 'I2C support' CONFIG_I2C
 
 if [ "$CONFIG_I2C" != "n" ]; then
-
    dep_tristate 'I2C bit-banging interfaces'  CONFIG_I2C_ALGOBIT $CONFIG_I2C
    if [ "$CONFIG_I2C_ALGOBIT" != "n" ]; then
       dep_tristate '  Philips style parallel port adapter' CONFIG_I2C_PHILIPSPAR $CONFIG_I2C_ALGOBIT $CONFIG_PARPORT
@@ -36,7 +35,7 @@
    if [ "$CONFIG_8xx" = "y" ]; then
       dep_tristate 'MPC8xx CPM I2C interface' CONFIG_I2C_ALGO8XX $CONFIG_I2C
       if [ "$CONFIG_RPXLITE" = "y" -o "$CONFIG_RPXCLASSIC" = "y" ]; then
-         dep_tristate '  Embedded Planet RPX Lite/Classic suppoort' CONFIG_I2C_RPXLITE $CONFIG_I2C_ALGO8XX
+         dep_tristate '  Embedded Planet RPX Lite/Classic support' CONFIG_I2C_RPXLITE $CONFIG_I2C_ALGO8XX
       fi
    fi
    if [ "$CONFIG_405" = "y" ]; then
@@ -55,14 +54,14 @@
       dep_tristate '  MAX1617 Temperature Sensor' CONFIG_I2C_MAX1617 $CONFIG_I2C_ALGO_SIBYTE
    fi
 
-  if [ "$CONFIG_SGI_IP22" = "y" ]; then
-     dep_tristate 'I2C SGI interfaces' CONFIG_I2C_ALGO_SGI $CONFIG_I2C
-  fi
+   if [ "$CONFIG_SGI_IP22" = "y" ]; then
+      dep_tristate 'I2C SGI interfaces' CONFIG_I2C_ALGO_SGI $CONFIG_I2C
+   fi
  
 # This is needed for automatic patch generation: sensors code starts here
 # This is needed for automatic patch generation: sensors code ends here
 
    dep_tristate 'I2C device interface' CONFIG_I2C_CHARDEV $CONFIG_I2C
-   dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C
+   dep_tristate 'I2C /proc interface (required for hardware sensors)' CONFIG_I2C_PROC $CONFIG_I2C $CONFIG_SYSCTL
 fi
 endmenu

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (2/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
  2004-01-11 13:51 ` [PATCH 2.4] i2c cleanups, third wave (1/8) Jean Delvare
@ 2004-01-11 13:59 ` Jean Delvare
  2004-01-11 14:08 ` [PATCH 2.4] i2c cleanups, third wave (3/8) Jean Delvare
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 13:59 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

Remove old debugging stuff ("SLO_IO") from two algorithms
(i2c-algo-bit and i2c-algo-ite). This is unused and wouldn't even
compile if commented out.

A similar patch was sent to Greg KH for linux 2.6 and was applied in
2.6.1-rc1.

Note that this patch was voluntarily generated using diff -U2, because
it contains only removals, so much context isn't required.


diff -U2 -rN linux-2.4.24-pre3/drivers/i2c/i2c-algo-bit.c linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-bit.c
--- linux-2.4.24-pre3/drivers/i2c/i2c-algo-bit.c	2003-12-31 14:50:59.000000000 +0100
+++ linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-bit.c	2004-01-05 09:44:26.000000000 +0100
@@ -44,20 +44,7 @@
  	/* debug the protocol by showing transferred bits */
 
-/* debugging - slow down transfer to have a look at the data .. 	*/
-/* I use this with two leds&resistors, each one connected to sda,scl 	*/
-/* respectively. This makes sure that the algorithm works. Some chips   */
-/* might not like this, as they have an internal timeout of some mils	*/
-/*
-#define SLO_IO      jif=jiffies;while(time_before_eq(jiffies, jif+i2c_table[minor].veryslow))\
-                        if (need_resched) schedule();
-*/
-
 
 /* ----- global variables ---------------------------------------------	*/
 
-#ifdef SLO_IO
-	int jif;
-#endif
-
 /* module parameters:
  */
@@ -89,7 +76,4 @@
 	setscl(adap,0);
 	udelay(adap->udelay);
-#ifdef SLO_IO
-	SLO_IO
-#endif
 }
 
@@ -124,7 +108,4 @@
 	}
 	DEBSTAT(printk(KERN_DEBUG "needed %ld jiffies\n", jiffies-start));
-#ifdef SLO_IO
-	SLO_IO
-#endif
 	return 0;
 } 
diff -U2 -rN linux-2.4.24-pre3/drivers/i2c/i2c-algo-ite.c linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-ite.c
--- linux-2.4.24-pre3/drivers/i2c/i2c-algo-ite.c	2003-12-31 14:50:59.000000000 +0100
+++ linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-ite.c	2004-01-05 09:43:53.000000000 +0100
@@ -61,20 +61,7 @@
 #define DEF_TIMEOUT 16
 
-/* debugging - slow down transfer to have a look at the data .. 	*/
-/* I use this with two leds&resistors, each one connected to sda,scl 	*/
-/* respectively. This makes sure that the algorithm works. Some chips   */
-/* might not like this, as they have an internal timeout of some mils	*/
-/*
-#define SLO_IO      jif=jiffies;while(jiffies<=jif+i2c_table[minor].veryslow)\
-                        if (need_resched) schedule();
-*/
-
 
 /* ----- global variables ---------------------------------------------	*/
 
-#ifdef SLO_IO
-	int jif;
-#endif
-
 /* module parameters:
  */

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (3/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
  2004-01-11 13:51 ` [PATCH 2.4] i2c cleanups, third wave (1/8) Jean Delvare
  2004-01-11 13:59 ` [PATCH 2.4] i2c cleanups, third wave (2/8) Jean Delvare
@ 2004-01-11 14:08 ` Jean Delvare
  2004-01-11 14:50 ` [PATCH 2.4] i2c cleanups, third wave (4/8) Jean Delvare
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 14:08 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

Remove bus scanning from various algorithms (i2c-algo-bit, i2c-algo-ite,
i2c-algo-pcf and i2c-algo-sibyte). This was discussed on the LM Sensors
mailing list:
http://archives.andrew.net.au/lm-sensors/msg05639.html
Main reason is that there is the i2cdetect user-space tools for that,
which works with all i2c busses (except i2c-isa) and does a better job.

A similar patch was sent to Greg KH for linux 2.6 and was applied in
2.6.1-rc1.

Note that this patch was voluntarily generated using diff -U2, because
it contains only removals, so much context isn't required.


diff -U2 -rN linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-bit.c linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-bit.c
--- linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-bit.c	2004-01-05 09:44:26.000000000 +0100
+++ linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-bit.c	2004-01-05 15:22:54.000000000 +0100
@@ -51,5 +51,4 @@
 static int i2c_debug;
 static int bit_test;	/* see if the line-setting functions work	*/
-static int bit_scan;	/* have a look at what's hanging 'round		*/
 
 /* --- setting states on the bus with the right timing: ---------------	*/
@@ -527,5 +526,4 @@
 int i2c_bit_add_bus(struct i2c_adapter *adap)
 {
-	int i;
 	struct i2c_algo_bit_data *bit_adap = adap->algo_data;
 
@@ -547,21 +545,4 @@
 	adap->retries = 3;	/* be replaced by defines	*/
 
-	/* scan bus */
-	if (bit_scan) {
-		int ack;
-		printk(KERN_INFO " i2c-algo-bit.o: scanning bus %s.\n",
-		       adap->name);
-		for (i = 0x00; i < 0xff; i+=2) {
-			i2c_start(bit_adap);
-			ack = i2c_outb(adap,i);
-			i2c_stop(bit_adap);
-			if (ack>0) {
-				printk("(%02x)",i>>1); 
-			} else 
-				printk("."); 
-		}
-		printk("\n");
-	}
-
 #ifdef MODULE
 	MOD_INC_USE_COUNT;
@@ -605,9 +586,7 @@
 
 MODULE_PARM(bit_test, "i");
-MODULE_PARM(bit_scan, "i");
 MODULE_PARM(i2c_debug,"i");
 
 MODULE_PARM_DESC(bit_test, "Test the lines of the bus to see if it is stuck");
-MODULE_PARM_DESC(bit_scan, "Scan for active chips on the bus");
 MODULE_PARM_DESC(i2c_debug,
             "debug level - 0 off; 1 normal; 2,3 more verbose; 9 bit-protocol");
diff -U2 -rN linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-ite.c linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-ite.c
--- linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-ite.c	2004-01-05 09:43:53.000000000 +0100
+++ linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-ite.c	2004-01-06 11:56:13.000000000 +0100
@@ -68,5 +68,4 @@
 static int i2c_debug=1;
 static int iic_test=0;	/* see if the line-setting functions work	*/
-static int iic_scan=0;	/* have a look at what's hanging 'round		*/
 
 /* --- setting states on the bus with the right timing: ---------------	*/
@@ -745,6 +744,4 @@
 int i2c_iic_add_bus(struct i2c_adapter *adap)
 {
-	int i;
-	short status;
 	struct i2c_algo_iic_data *iic_adap = adap->algo_data;
 
@@ -774,22 +771,4 @@
 	iic_init(iic_adap);
 
-	/* scan bus */
-	/* By default scanning the bus is turned off. */
-	if (iic_scan) {
-		printk(KERN_INFO " i2c-algo-ite: scanning bus %s.\n",
-		       adap->name);
-		for (i = 0x00; i < 0xff; i+=2) {
-			iic_outw(iic_adap, ITE_I2CSAR, i);
-			iic_start(iic_adap);
-			if ( (wait_for_pin(iic_adap, &status) == 0) && 
-			    ((status & ITE_I2CHSR_DNE) == 0) ) { 
-				printk(KERN_INFO "\n(%02x)\n",i>>1); 
-			} else {
-				printk(KERN_INFO "."); 
-				iic_reset(iic_adap);
-			}
-			udelay(iic_adap->udelay);
-		}
-	}
 	return 0;
 }
@@ -834,9 +813,7 @@
 
 MODULE_PARM(iic_test, "i");
-MODULE_PARM(iic_scan, "i");
 MODULE_PARM(i2c_debug,"i");
 
 MODULE_PARM_DESC(iic_test, "Test if the I2C bus is available");
-MODULE_PARM_DESC(iic_scan, "Scan for active chips on the bus");
 MODULE_PARM_DESC(i2c_debug,
         "debug level - 0 off; 1 normal; 2,3 more verbose; 9 iic-protocol");
diff -U2 -rN linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-pcf.c linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-pcf.c
--- linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-pcf.c	2003-12-31 14:50:59.000000000 +0100
+++ linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-pcf.c	2004-01-06 12:01:10.000000000 +0100
@@ -53,5 +53,4 @@
  */
 static int i2c_debug=0;
-static int pcf_scan=0;	/* have a look at what's hanging 'round		*/
 
 /* --- setting states on the bus with the right timing: ---------------	*/
@@ -458,5 +457,5 @@
 int i2c_pcf_add_bus(struct i2c_adapter *adap)
 {
-	int i, status;
+	int i;
 	struct i2c_algo_pcf_data *pcf_adap = adap->algo_data;
 
@@ -481,28 +480,4 @@
 
 	i2c_add_adapter(adap);
-
-	/* scan bus */
-	if (pcf_scan) {
-		printk(KERN_INFO " i2c-algo-pcf.o: scanning bus %s.\n",
-		       adap->name);
-		for (i = 0x00; i < 0xff; i+=2) {
-			if (wait_for_bb(pcf_adap)) {
-    			printk(KERN_INFO " i2c-algo-pcf.o: scanning bus %s - TIMEOUTed.\n",
-		           adap->name);
-			    break;
-			}
-			i2c_outb(pcf_adap, i);
-			i2c_start(pcf_adap);
-			if ((wait_for_pin(pcf_adap, &status) >= 0) && 
-			    ((status & I2C_PCF_LRB) == 0)) { 
-				printk("(%02x)",i>>1); 
-			} else {
-				printk("."); 
-			}
-			i2c_stop(pcf_adap);
-			udelay(pcf_adap->udelay);
-		}
-		printk("\n");
-	}
 	return 0;
 }
@@ -537,12 +512,8 @@
 MODULE_LICENSE("GPL");
 
-MODULE_PARM(pcf_scan, "i");
 MODULE_PARM(i2c_debug,"i");
-
-MODULE_PARM_DESC(pcf_scan, "Scan for active chips on the bus");
 MODULE_PARM_DESC(i2c_debug,
         "debug level - 0 off; 1 normal; 2,3 more verbose; 9 pcf-protocol");
 
-
 int init_module(void) 
 {
diff -U2 -rN linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-sibyte.c linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-sibyte.c
--- linux-2.4.24-pre3-k1/drivers/i2c/i2c-algo-sibyte.c	2003-08-25 13:44:41.000000000 +0200
+++ linux-2.4.24-pre3-k2/drivers/i2c/i2c-algo-sibyte.c	2004-01-06 12:09:46.000000000 +0100
@@ -40,10 +40,5 @@
 #define SMB_CSR(a,r) ((long)(a->reg_base + r))
 
-/* ----- global variables ---------------------------------------------	*/
-
-/* module parameters:
- */
-static int bit_scan=0;	/* have a look at what's hanging 'round		*/
-
+/* ----- functions ---------------------------------------------------- */
 
 static int smbus_xfer(struct i2c_adapter *i2c_adap, u16 addr, 
@@ -152,5 +147,4 @@
 int i2c_sibyte_add_bus(struct i2c_adapter *i2c_adap, int speed)
 {
-	int i;
 	struct i2c_algo_sibyte_data *adap = i2c_adap->algo_data;
 
@@ -164,22 +158,4 @@
         csr_out32(0, SMB_CSR(adap,R_SMB_CONTROL));
 
-	/* scan bus */
-	if (bit_scan) {
-                union i2c_smbus_data data;
-                int rc;
-		printk(KERN_INFO " i2c-algo-sibyte.o: scanning bus %s.\n",
-		       i2c_adap->name);
-		for (i = 0x00; i < 0x7f; i++) {
-                        /* XXXKW is this a realistic probe? */
-                        rc = smbus_xfer(i2c_adap, i, 0, I2C_SMBUS_READ, 0,
-                                        I2C_SMBUS_BYTE_DATA, &data);
-			if (!rc) {
-				printk("(%02x)",i); 
-			} else 
-				printk("."); 
-		}
-		printk("\n");
-	}
-
 #ifdef MODULE
 	MOD_INC_USE_COUNT;
@@ -217,6 +193,4 @@
 MODULE_AUTHOR("Kip Walker, Broadcom Corp.");
 MODULE_DESCRIPTION("SiByte I2C-Bus algorithm");
-MODULE_PARM(bit_scan, "i");
-MODULE_PARM_DESC(bit_scan, "Scan for active chips on the bus");
 MODULE_LICENSE("GPL");
 

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (4/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (2 preceding siblings ...)
  2004-01-11 14:08 ` [PATCH 2.4] i2c cleanups, third wave (3/8) Jean Delvare
@ 2004-01-11 14:50 ` Jean Delvare
  2004-01-11 15:04 ` [PATCH 2.4] i2c cleanups, third wave (5/8) Jean Delvare
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 14:50 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

This patch doesn't really focus on the i2c subsystem, but is still
i2c-related. It concerns the media/video subsystem, where I discovered a
few incorrectnesses as I was working on my i2c patches.

* i2c-old.c contains old init stuff, obviously inherted from the times
of linux 2.2, which should be cleared. The BUZ and LML33 drivers are now
i2c drivers, not i2c-old ones.
* The Makefile needs a few adjustements.
* saa7146.h should include i2c-old.h, not i2c.h.

The thin part of this patch that also applies to linux 2.6 has been sent
to Greg KH.


diff -ruN linux-2.4.24-pre3/drivers/media/video/i2c-old.c linux-2.4.24-pre3-k3/drivers/media/video/i2c-old.c
--- linux-2.4.24-pre3/drivers/media/video/i2c-old.c	2001-09-30 21:26:06.000000000 +0200
+++ linux-2.4.24-pre3-k3/drivers/media/video/i2c-old.c	2004-01-06 14:01:45.000000000 +0100
@@ -36,28 +36,11 @@
 static struct i2c_driver *drivers[I2C_DRIVER_MAX];
 static int bus_count = 0, driver_count = 0;
 
-#ifdef CONFIG_VIDEO_BUZ
-extern int saa7111_init(void);
-extern int saa7185_init(void);
-#endif
-#ifdef CONFIG_VIDEO_LML33
-extern int bt819_init(void);
-extern int bt856_init(void);
-#endif
-
 int i2c_init(void)
 {
 	printk(KERN_INFO "i2c: initialized%s\n",
 		scan ? " (i2c bus scan enabled)" : "");
-	/* anything to do here ? */
-#ifdef CONFIG_VIDEO_BUZ
-	saa7111_init();
-	saa7185_init();
-#endif
-#ifdef CONFIG_VIDEO_LML33
-	bt819_init();
-	bt856_init();
-#endif
+
 	return 0;
 }
 
diff -ruN linux-2.4.24-pre3/drivers/media/video/Makefile linux-2.4.24-pre3-k3/drivers/media/video/Makefile
--- linux-2.4.24-pre3/drivers/media/video/Makefile	2003-12-31 14:51:01.000000000 +0100
+++ linux-2.4.24-pre3-k3/drivers/media/video/Makefile	2004-01-06 14:01:14.000000000 +0100
@@ -40,7 +40,7 @@
 
 obj-$(CONFIG_VIDEO_ZR36120) += zoran.o i2c-old.o
 obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o i2c-old.o
-obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o i2c-old.o
+obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o
 obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o
 obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o
 obj-$(CONFIG_VIDEO_W9966) += w9966.o
@@ -48,11 +48,10 @@
 obj-$(CONFIG_VIDEO_ZORAN_BUZ) += saa7111.o saa7185.o
 obj-$(CONFIG_VIDEO_ZORAN_DC10) += saa7110.o adv7175.o
 obj-$(CONFIG_VIDEO_ZORAN_LML33) += bt819.o bt856.o
-obj-$(CONFIG_VIDEO_LML33) += bt856.o bt819.o
 obj-$(CONFIG_VIDEO_PMS) += pms.o
 obj-$(CONFIG_VIDEO_PLANB) += planb.o
 obj-$(CONFIG_VIDEO_VINO) += saa7191.o indycam.o vino.o
-obj-$(CONFIG_VIDEO_STRADIS) += stradis.o
+obj-$(CONFIG_VIDEO_STRADIS) += stradis.o i2c-old.o
 obj-$(CONFIG_VIDEO_CPIA) += cpia.o
 obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o
 obj-$(CONFIG_VIDEO_CPIA_USB) += cpia_usb.o
@@ -81,8 +80,8 @@
 
 fastdep:
 
-zoran.o: zr36120.o zr36120_i2c.o zr36120_mem.o
-	$(LD) $(LD_RFLAG) -r -o $@ zr36120.o zr36120_i2c.o zr36120_mem.o
+zoran.o: $(zoran-objs)
+	$(LD) $(LD_RFLAG) -r -o $@ $(zoran-objs)
 
 bttv.o: $(bttv-objs)
 	$(LD) $(LD_RFLAG) -r -o $@ $(bttv-objs)
diff -ruN linux-2.4.24-pre3/drivers/media/video/saa7146.h linux-2.4.24-pre3-k3/drivers/media/video/saa7146.h
--- linux-2.4.24-pre3/drivers/media/video/saa7146.h	2000-12-11 22:15:51.000000000 +0100
+++ linux-2.4.24-pre3-k3/drivers/media/video/saa7146.h	2004-01-06 14:02:45.000000000 +0100
@@ -25,7 +25,7 @@
 #include <linux/types.h>
 #include <linux/wait.h>
 
-#include <linux/i2c.h>
+#include <linux/i2c-old.h>
 #include <linux/videodev.h>
 
 #ifndef O_NONCAP  

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (5/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (3 preceding siblings ...)
  2004-01-11 14:50 ` [PATCH 2.4] i2c cleanups, third wave (4/8) Jean Delvare
@ 2004-01-11 15:04 ` Jean Delvare
  2004-01-11 15:10 ` [PATCH 2.4] i2c cleanups, third wave (6/8) Jean Delvare
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 15:04 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

This patch defines I2C_SMBUS_BLOCK_MAX and I2C_SMBUS_I2C_BLOCK_MAX,
those values were previously hardcoded in several places.

Part of the work was done by Kyösti Mälkki. Original comment follows:
***
Message block size.
***

The patch also fixes an incorrect error message and a potential buffer
overrun.

diff -ru linux-2.4.25-pre4-k4/drivers/i2c/i2c-core.c linux-2.4.25-pre4-k5/drivers/i2c/i2c-core.c
--- linux-2.4.25-pre4-k4/drivers/i2c/i2c-core.c	Sat Jan 10 20:27:50 2004
+++ linux-2.4.25-pre4-k5/drivers/i2c/i2c-core.c	Sun Jan 11 10:33:12 2004
@@ -1062,8 +1062,8 @@
 {
 	union i2c_smbus_data data;
 	int i;
-	if (length > 32)
-		length = 32;
+	if (length > I2C_SMBUS_BLOCK_MAX)
+		length = I2C_SMBUS_BLOCK_MAX;
 	for (i = 1; i <= length; i++)
 		data.block[i] = values[i-1];
 	data.block[0] = length;
@@ -1077,8 +1077,8 @@
 {
 	union i2c_smbus_data data;
 	int i;
-	if (length > 32)
-		length = 32;
+	if (length > I2C_SMBUS_I2C_BLOCK_MAX)
+		length = I2C_SMBUS_I2C_BLOCK_MAX;
 	for (i = 1; i <= length; i++)
 		data.block[i] = values[i-1];
 	data.block[0] = length;
@@ -1152,10 +1152,10 @@
 			return -1;
 		} else {
 			msg[0].len = data->block[0] + 2;
-			if (msg[0].len > 34) {
+			if (msg[0].len > I2C_SMBUS_BLOCK_MAX + 2) {
 				printk(KERN_ERR "i2c-core.o: smbus_access called with "
 				       "invalid block write size (%d)\n",
-				       msg[0].len);
+				       data->block[0]);
 				return -1;
 			}
 			for (i = 1; i <= msg[0].len; i++)
diff -ru linux-2.4.25-pre4-k4/include/linux/i2c.h linux-2.4.25-pre4-k5/include/linux/i2c.h
--- linux-2.4.25-pre4-k4/include/linux/i2c.h	Sat Jan 10 20:27:55 2004
+++ linux-2.4.25-pre4-k5/include/linux/i2c.h	Sun Jan 11 10:46:48 2004
@@ -413,10 +413,13 @@
 /* 
  * Data for SMBus Messages 
  */
+#define I2C_SMBUS_BLOCK_MAX	32	/* As specified in SMBus standard */	
+#define I2C_SMBUS_I2C_BLOCK_MAX	32	/* Not specified but we use same structure */
 union i2c_smbus_data {
 	__u8 byte;
 	__u16 word;
-	__u8 block[33]; /* block[0] is used for length */
+	__u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for length */
+	                  /* one more for read length in block process call */
 };
 
 /* smbus_access read or write markers */


-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (6/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (4 preceding siblings ...)
  2004-01-11 15:04 ` [PATCH 2.4] i2c cleanups, third wave (5/8) Jean Delvare
@ 2004-01-11 15:10 ` Jean Delvare
  2004-01-11 15:20 ` [PATCH 2.4] i2c cleanups, third wave (7/8) Jean Delvare
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 15:10 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

Remove two old, unused functions from i2c-proc, left over from linux 2.2
times.

Original patch by Kyösti Mälkki. Original comment follows:
***
Drop 2.2 code.
***

--- linux-2.4.25-pre4-k5/drivers/i2c/i2c-proc.c	Sat Jan 10 20:27:50 2004
+++ linux-2.4.25-pre4-k6/drivers/i2c/i2c-proc.c	Sun Jan 11 11:50:01 2004
@@ -213,49 +213,6 @@
 	}
 }
 
-/* Monitor access for /proc/sys/dev/sensors; make unloading i2c-proc.o 
-   impossible if some process still uses it or some file in it */
-void i2c_fill_inode(struct inode *inode, int fill)
-{
-	if (fill)
-		MOD_INC_USE_COUNT;
-	else
-		MOD_DEC_USE_COUNT;
-}
-
-/* Monitor access for /proc/sys/dev/sensors/ directories; make unloading
-   the corresponding module impossible if some process still uses it or
-   some file in it */
-void i2c_dir_fill_inode(struct inode *inode, int fill)
-{
-	int i;
-	struct i2c_client *client;
-
-#ifdef DEBUG
-	if (!inode) {
-		printk("i2c-proc.o: Warning: inode NULL in fill_inode()\n");
-		return;
-	}
-#endif				/* def DEBUG */
-
-	for (i = 0; i < SENSORS_ENTRY_MAX; i++)
-		if (i2c_clients[i]
-		    && (i2c_inodes[i] == inode->i_ino)) break;
-#ifdef DEBUG
-	if (i == SENSORS_ENTRY_MAX) {
-		printk
-		    ("i2c-proc.o: Warning: inode (%ld) not found in fill_inode()\n",
-		     inode->i_ino);
-		return;
-	}
-#endif				/* def DEBUG */
-	client = i2c_clients[i];
-	if (fill)
-		client->driver->inc_use(client);
-	else
-		client->driver->dec_use(client);
-}
-
 int i2c_proc_chips(ctl_table * ctl, int write, struct file *filp,
 		       void *buffer, size_t * lenp)
 {


-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (7/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (5 preceding siblings ...)
  2004-01-11 15:10 ` [PATCH 2.4] i2c cleanups, third wave (6/8) Jean Delvare
@ 2004-01-11 15:20 ` Jean Delvare
  2004-01-11 15:28 ` [PATCH 2.4] i2c cleanups, third wave (8/8) Jean Delvare
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 15:20 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

Clean up various i2c algorithms:

* Remove empty algo_control function (i2c-algo-bit, i2c-algo-pcf,
i2c-algo-sibyte).
* Convert i2c_algorithm init to C99 style (i2c-algo-bit, i2c-algo-ite,
i2c-algo-pcf, i2c-algo-sibyte).

Original patch by Kyösti Mälkki.

diff -ru linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-bit.c linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-bit.c
--- linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-bit.c	Sat Jan 10 21:16:02 2004
+++ linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-bit.c	Sun Jan 11 13:02:02 2004
@@ -494,12 +494,6 @@
 	return num;
 }
 
-static int algo_control(struct i2c_adapter *adapter, 
-	unsigned int cmd, unsigned long arg)
-{
-	return 0;
-}
-
 static u32 bit_func(struct i2c_adapter *adap)
 {
 	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | 
@@ -510,14 +504,10 @@
 /* -----exported algorithm data: -------------------------------------	*/
 
 static struct i2c_algorithm i2c_bit_algo = {
-	"Bit-shift algorithm",
-	I2C_ALGO_BIT,
-	bit_xfer,
-	NULL,
-	NULL,				/* slave_xmit		*/
-	NULL,				/* slave_recv		*/
-	algo_control,			/* ioctl		*/
-	bit_func,			/* functionality	*/
+	.name		= "Bit-shift algorithm",
+	.id		= I2C_ALGO_BIT,
+	.master_xfer	= bit_xfer,
+	.functionality	= bit_func,
 };
 
 /* 
diff -ru linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-ite.c linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-ite.c
--- linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-ite.c	Sat Jan 10 21:16:02 2004
+++ linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-ite.c	Sun Jan 11 13:01:10 2004
@@ -727,14 +727,11 @@
 /* -----exported algorithm data: -------------------------------------	*/
 
 static struct i2c_algorithm iic_algo = {
-	"ITE IIC algorithm",
-	I2C_ALGO_IIC,
-	iic_xfer,		/* master_xfer	*/
-	NULL,				/* smbus_xfer	*/
-	NULL,				/* slave_xmit		*/
-	NULL,				/* slave_recv		*/
-	algo_control,			/* ioctl		*/
-	iic_func,			/* functionality	*/
+	.name		= "ITE IIC algorithm",
+	.id		= I2C_ALGO_IIC,
+	.master_xfer	= iic_xfer,
+	.algo_control	= algo_control, /* ioctl */
+	.functionality	= iic_func,
 };
 
 
diff -ru linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-pcf.c linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-pcf.c
--- linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-pcf.c	Sat Jan 10 21:16:02 2004
+++ linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-pcf.c	Sun Jan 11 12:57:49 2004
@@ -426,12 +426,6 @@
 	return (i);
 }
 
-static int algo_control(struct i2c_adapter *adapter, 
-	unsigned int cmd, unsigned long arg)
-{
-	return 0;
-}
-
 static u32 pcf_func(struct i2c_adapter *adap)
 {
 	return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR | 
@@ -441,14 +435,10 @@
 /* -----exported algorithm data: -------------------------------------	*/
 
 static struct i2c_algorithm pcf_algo = {
-	"PCF8584 algorithm",
-	I2C_ALGO_PCF,
-	pcf_xfer,
-	NULL,
-	NULL,				/* slave_xmit		*/
-	NULL,				/* slave_recv		*/
-	algo_control,			/* ioctl		*/
-	pcf_func,			/* functionality	*/
+	.name		= "PCF8584 algorithm",
+	.id		= I2C_ALGO_PCF,
+	.master_xfer	= pcf_xfer,
+	.functionality	= pcf_func,
 };
 
 /* 
diff -ru linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-sibyte.c linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-sibyte.c
--- linux-2.4.25-pre4-k6/drivers/i2c/i2c-algo-sibyte.c	Sat Jan 10 21:16:02 2004
+++ linux-2.4.25-pre4-k7/drivers/i2c/i2c-algo-sibyte.c	Sun Jan 11 12:56:49 2004
@@ -115,12 +115,6 @@
         return 0;
 }
 
-static int algo_control(struct i2c_adapter *adapter, 
-	unsigned int cmd, unsigned long arg)
-{
-	return 0;
-}
-
 static u32 bit_func(struct i2c_adapter *adap)
 {
 	return (I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
@@ -131,14 +125,10 @@
 /* -----exported algorithm data: -------------------------------------	*/
 
 static struct i2c_algorithm i2c_sibyte_algo = {
-	"SiByte algorithm",
-	I2C_ALGO_SIBYTE,
-	NULL,                           /* master_xfer          */
-	smbus_xfer,                   	/* smbus_xfer           */
-	NULL,				/* slave_xmit		*/
-	NULL,				/* slave_recv		*/
-	algo_control,			/* ioctl		*/
-	bit_func,			/* functionality	*/
+	.name		= "SiByte algorithm",
+	.id		= I2C_ALGO_SIBYTE,
+	.smbus_xfer	= smbus_xfer,
+	.functionality	= bit_func,
 };
 
 /* 


-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 2.4] i2c cleanups, third wave (8/8)
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (6 preceding siblings ...)
  2004-01-11 15:20 ` [PATCH 2.4] i2c cleanups, third wave (7/8) Jean Delvare
@ 2004-01-11 15:28 ` Jean Delvare
  2004-01-12  1:48 ` [PATCH 2.4] i2c cleanups, third wave Mike Fedyk
  2004-01-14 12:55 ` Marcelo Tosatti
  9 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-11 15:28 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

This last patch fixes missing spaces in an error message in i2c-core.c.
Original patch by Kyösti Mälkki.

Thanks!

--- linux-2.4.25-pre4-k7/drivers/i2c/i2c-core.c	Sun Jan 11 10:33:12 2004
+++ linux-2.4.25-pre4-k8/drivers/i2c/i2c-core.c	Sun Jan 11 13:51:11 2004
@@ -359,8 +359,8 @@
 						       "unregistering driver "
 						       "`%s', the client at "
 						       "address %02x of "
-						       "adapter `%s' could not"
-						       "be detached; driver"
+						       "adapter `%s' could not "
+						       "be detached; driver "
 						       "not unloaded!",
 						       driver->name,
 						       client->addr,



-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2.4] i2c cleanups, third wave
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (7 preceding siblings ...)
  2004-01-11 15:28 ` [PATCH 2.4] i2c cleanups, third wave (8/8) Jean Delvare
@ 2004-01-12  1:48 ` Mike Fedyk
  2004-01-14 18:30   ` Jean Delvare
  2004-01-14 12:55 ` Marcelo Tosatti
  9 siblings, 1 reply; 13+ messages in thread
From: Mike Fedyk @ 2004-01-12  1:48 UTC (permalink / raw)
  To: LKML, LM Sensors; +Cc: Marcelo Tosatti

On Sun, Jan 11, 2004 at 02:42:14PM +0100, Jean Delvare wrote:
> I will be sending 8 patches to you, based on linux-2.4.25-pre4. They
> contain cleanups for the i2c subsystem code, ported from LM Sensors' i2c
> CVS repository [1]. Since that repository was also the base of the i2c
> subsystem as is now in linux 2.6, one might also consider these patches
> as backports from linux 2.6.

How about some patches to add some more sensors to the 2.4 kernel, like the
ones already in 2.6?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2.4] i2c cleanups, third wave
  2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
                   ` (8 preceding siblings ...)
  2004-01-12  1:48 ` [PATCH 2.4] i2c cleanups, third wave Mike Fedyk
@ 2004-01-14 12:55 ` Marcelo Tosatti
  2004-01-14 14:55   ` Jean Delvare
  9 siblings, 1 reply; 13+ messages in thread
From: Marcelo Tosatti @ 2004-01-14 12:55 UTC (permalink / raw)
  To: LKML, LM Sensors; +Cc: Marcelo Tosatti



On Sun, 11 Jan 2004, Jean Delvare wrote:

> I will be sending 8 patches to you, based on linux-2.4.25-pre4. They
> contain cleanups for the i2c subsystem code, ported from LM Sensors' i2c
> CVS repository [1]. Since that repository was also the base of the i2c
> subsystem as is now in linux 2.6, one might also consider these patches
> as backports from linux 2.6.
>
> Details about what the patch does and credits will be found with each
> patch.

Jean,

>From what I understand all patches are cleanups except the bus scanning
removal (which fixes a problem on ThinkPad?).

I want to merge only bug fixes or practical corrections.

Please correct me if I overlooked the patches and they contain bug fixes.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2.4] i2c cleanups, third wave
  2004-01-14 12:55 ` Marcelo Tosatti
@ 2004-01-14 14:55   ` Jean Delvare
  0 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-14 14:55 UTC (permalink / raw)
  To: Marcelo Tosatti; +Cc: LKML, LM Sensors

Hi Marcelo,

> From what I understand all patches are cleanups except the bus
> scanning removal (which fixes a problem on ThinkPad?).
> 
> I want to merge only bug fixes or practical corrections.
> 
> Please correct me if I overlooked the patches and they contain bug
> fixes.

Here is a summary of what each patch does (with the focus set on bug
fix
vs. cleanups), so that you can decide what you want to merge.

(1/8) One dependency fixed (problem was reported at least once), one
typo fixed. The rest is about layout and can be ignored.

(2/8) Can't be called a bug fix because the code is commented for now,
but it would not compile if it were restored. You decide.

(3/8) Bus scanning is known to be possibly harmful, although no problem
was reported with these specific modules. Long story short, the
Thinkpad syndrom is that bus scanning PIIX4 busses where 24RF08
chipsets live (which is the case of many Thinkpads) with our
sensors-detect script used to break them until we could find a subtle
fix. As a consequence, our policy and recommendation is that bus
scanning should be avoided. But there was no problem reported so far
with these specific modules. So, once again you decide.

(4/8) Two makefile bug fixes and one bad include fix. The part that
affects i2c-old.h and a large part that affects Makefile are cleanups
that you can ignore.

(5/8) This one is more about code readability/maintainability, but
still fixes a bogus error message, and, more importantly, a potential
buffer overrun. At least the potential buffer overrun should be fixed.

(6/8) Cleanups only, can be discarded.

(7/8) Cleanups only, can be discarded.

(8/8) Missing spaces in an error message. You decide.

Now, a few personal comments:

1* I can submit "light" versions of the patches that only contain the
parts you want, just tell me what they are.

2* There is nothing in these patches that I would consider dangerous,
which admitedly wasn't the case with the previous wave. With a bit more
experience, I wouldn't have submitted patch (3/5) (locks) in the
previous wave. For this wave, If I were to decide, according to your
"nothing dangerous" concerns, I'd discard patches 6 and 7, keep only
the fixes from 4 and 5, and keep 1, 2, 3 and 8. If you really insist so
that only bugs are fixed, this mean one item in 1, a few in 4 and one
in 5. Again, you decide.

3* This was obviously the last wave of patches I submitted, since we're
reaching (or more likely have already reached) the point of
maintainance only for the 2.4 kernel. I'll of course continue to do my
job as the i2c subsystem maintainer and provide fixes to any critial
bug that would be discovered.

Hopefully this will let you decide what you want to be done.

Thanks,
Jean

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH 2.4] i2c cleanups, third wave
  2004-01-12  1:48 ` [PATCH 2.4] i2c cleanups, third wave Mike Fedyk
@ 2004-01-14 18:30   ` Jean Delvare
  0 siblings, 0 replies; 13+ messages in thread
From: Jean Delvare @ 2004-01-14 18:30 UTC (permalink / raw)
  To: Mike Fedyk; +Cc: linux-kernel, sensors

> How about some patches to add some more sensors to the 2.4 kernel,
> like the ones already in 2.6?

The 2.4 kernel has reached a maintainance-only point so there is no way
lm_sensors could be officially merged into it now, especially since the
i2c layer itself would have to be significantly reworked before.

So your options are either to patch your 2.4 tree using the i2c patch
and additional drivers we provide, or to jump to Linux 2.6.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2004-01-14 18:30 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-11 13:42 [PATCH 2.4] i2c cleanups, third wave Jean Delvare
2004-01-11 13:51 ` [PATCH 2.4] i2c cleanups, third wave (1/8) Jean Delvare
2004-01-11 13:59 ` [PATCH 2.4] i2c cleanups, third wave (2/8) Jean Delvare
2004-01-11 14:08 ` [PATCH 2.4] i2c cleanups, third wave (3/8) Jean Delvare
2004-01-11 14:50 ` [PATCH 2.4] i2c cleanups, third wave (4/8) Jean Delvare
2004-01-11 15:04 ` [PATCH 2.4] i2c cleanups, third wave (5/8) Jean Delvare
2004-01-11 15:10 ` [PATCH 2.4] i2c cleanups, third wave (6/8) Jean Delvare
2004-01-11 15:20 ` [PATCH 2.4] i2c cleanups, third wave (7/8) Jean Delvare
2004-01-11 15:28 ` [PATCH 2.4] i2c cleanups, third wave (8/8) Jean Delvare
2004-01-12  1:48 ` [PATCH 2.4] i2c cleanups, third wave Mike Fedyk
2004-01-14 18:30   ` Jean Delvare
2004-01-14 12:55 ` Marcelo Tosatti
2004-01-14 14:55   ` Jean Delvare

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).