i2c driver changes for 2.5.64

Hi,

Here's a set of i2c driver changes that start the conversion of the i2c core and drivers over to the kernel driver model. Eventually this will allow all of the sysctl and proc mess to be removed for this subsystem.

These patches add i2c driver bus and i2c adapter driver support to the driver core. They also export a needed symbol from the driver core (which Pat Mochel agreed with doing.) The patches also add three i2c controllers that have been in the i2c cvs tree for a long time, and are on a lot of people's machines.

The i2c core needs Christoph's previous patches to work properly, and with that patch, and these patches, it all works properly on my machines (tested on 4 different types of i2c controllers.)

Oh, and the i2c development team has given the ok for me to send these patches to you, and for me to do this work.

Please pull from: bk://kernel.bkbits.net/gregkh/linux/i2c-2.5

Things left to do after this:
- clean up #ifdef mess in i2c controllers
- fix the printk() calls to use proper levels
- add i2c controller driver core support (present in the patch I previously sent to lkml).
- add i2c device core support.

thanks,

greg k-h

 arch/i386/kernel/dmi_scan.c      |    3 
 drivers/base/platform.c          |    3 
 drivers/i2c/busses/Kconfig       |   62 +++
 drivers/i2c/busses/Makefile      |    3 
 drivers/i2c/busses/i2c-ali15x3.c |  625 +++++++++++++++++++++++++++++-
 drivers/i2c/busses/i2c-amd756.c  |    3 
 drivers/i2c/busses/i2c-amd8111.c |    5 
 drivers/i2c/busses/i2c-i801.c    |  789 +++++++++++++++++++++++++++++++++++++--
 drivers/i2c/busses/i2c-piix4.c   |  651 ++++++++++++++++++++++++++++----
 drivers/i2c/i2c-core.c           |   46 ++
 include/linux/device.h           |    1 
 include/linux/i2c.h              |    5 
 12 files changed, 2063 insertions(+), 133 deletions(-)

-----

[email protected], 2003-03-13 16:39:40-08:00, [email protected]
i2c: add driver model support to i2c adapter drivers

 drivers/i2c/busses/i2c-ali15x3.c |    6 ++++--
 drivers/i2c/busses/i2c-amd756.c  |    3 +++
 drivers/i2c/busses/i2c-amd8111.c |    5 ++++-
 drivers/i2c/busses/i2c-i801.c    |    5 ++++-
 drivers/i2c/busses/i2c-piix4.c   |    3 +++
 drivers/i2c/i2c-core.c           |   13 +++++++++++++
 include/linux/i2c.h              |    2 ++
 7 files changed, 33 insertions(+), 4 deletions(-)

------

[email protected], 2003-03-13 16:37:27-08:00, [email protected]
driver core: Export the legacy_bus structure for drivers to use.

 drivers/base/platform.c |    3 ++-
 include/linux/device.h  |    1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

------

[email protected], 2003-03-13 12:26:39-08:00, [email protected]
i2c: add i2c sysfs bus support.

 drivers/i2c/i2c-core.c |   33 ++++++++++++++++++++++++++++++---
 include/linux/i2c.h    |    3 +++
 2 files changed, 33 insertions(+), 3 deletions(-)

------

[email protected], 2003-03-13 12:16:52-08:00, [email protected]
i2c: i2c-piix4.c: Clean up the ibm dma scan logic

Also export the is_unsafe_smbus variable, which is needed.

 arch/i386/kernel/dmi_scan.c    |    3 +++
 drivers/i2c/busses/i2c-piix4.c |   20 ++------------------
 2 files changed, 5 insertions(+), 18 deletions(-)

------

[email protected], 2003-03-13 11:59:13-08:00, [email protected]
i2c: get i2c-piix4 driver to actually bind to a PCI device.

 drivers/i2c/busses/i2c-piix4.c |   99 +++++++++++++++++++++--------------------
 1 files changed, 52 insertions(+), 47 deletions(-)

------

[email protected], 2003-03-13 11:52:26-08:00, [email protected]
i2c: add bus driver for Intel PIIX4 devices

This is from the i2c CVS tree.

 drivers/i2c/busses/Kconfig     |   25 +
 drivers/i2c/busses/Makefile    |    1 
 drivers/i2c/busses/i2c-piix4.c |  529 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 554 insertions(+), 1 deletion(-)

------

[email protected], 2003-03-13 11:38:03-08:00, [email protected]
i2c: get i2c-i801 driver to actually bind to a PCI device.

 drivers/i2c/busses/i2c-i801.c |   74 +++++++++++++++++++++---------------------
 1 files changed, 38 insertions(+), 36 deletions(-)

------

[email protected], 2003-03-13 11:15:15-08:00, [email protected]
i2c: add bus driver for Intel 801 devices

This is from the i2c CVS tree.

 drivers/i2c/busses/Kconfig    |   23 +
 drivers/i2c/busses/Makefile   |    1 
 drivers/i2c/busses/i2c-i801.c |  710 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 734 insertions(+)

------

[email protected], 2003-03-13 10:50:41-08:00, [email protected]
i2c: get i2c-ali15x3 driver to actually bind to a PCI device.

 drivers/i2c/busses/i2c-ali15x3.c |   32 +++++++++-----------------------
 1 files changed, 9 insertions(+), 23 deletions(-)

------

[email protected], 2003-03-13 10:31:07-08:00, [email protected]
i2c: add bus driver for ALI15x3 devices

This is from the i2c CVS tree.

 drivers/i2c/busses/Kconfig       |   14 
 drivers/i2c/busses/Makefile      |    1 
 drivers/i2c/busses/i2c-ali15x3.c |  587 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 602 insertions(+)

------

ChangeSet 1.1105, 2003/03/13 10:31:07-08:00, [email protected]

i2c: add bus driver for ALI15x3 devices

This is from the i2c CVS tree.

 drivers/i2c/busses/Kconfig       |   14 
 drivers/i2c/busses/Makefile      |    1 
 drivers/i2c/busses/i2c-ali15x3.c |  587 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 602 insertions(+)

diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
@@ -5,6 +5,20 @@
 
 menu "I2C Hardware Sensors Mainboard support"
 
+config I2C_ALI15X3
+	tristate "  ALI 15x3"
+	depends on I2C && I2C_PROC && PCI && EXPERIMENTAL
+	help
+	  If you say yes to this option, support will be included for the
+	  Acer Labs Inc. (ALI) M1514 and M1543 motherboard I2C interfaces.
+
+	  This can also be built as a module.  If so, the module will be
+	  called i2c-ali15x3.
+
+	  You will also need the latest user-space utilties: you can find them
+	  in the lm_sensors package, which you can download at
+	  http://www.lm-sensors.nu
+
 config I2C_AMD756
 	tristate "  AMD 756/766"
 	depends on I2C && I2C_PROC

diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
@@ -2,5 +2,6 @@
 # Makefile for the kernel hardware sensors bus drivers.
 #
 
+obj-$(CONFIG_I2C_ALI15X3)	+= i2c-ali15x3.o
 obj-$(CONFIG_I2C_AMD756)	+= i2c-amd756.o
 obj-$(CONFIG_I2C_AMD8111)	+= i2c-amd8111.o

ChangeSet 1.1106, 2003/03/13 10:50:41-08:00, [email protected]

i2c: get i2c-ali15x3 driver to actually bind to a PCI device.

 drivers/i2c/busses/i2c-ali15x3.c |   32 +++++++++-----------------------
 1 files changed, 9 insertions(+), 23 deletions(-)

diff -Nru a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
@@ -135,32 +135,11 @@
 
 static unsigned short ali15x3_smba = 0;
 
-/* Detect whether a ALI15X3 can be found, and initialize it, where necessary.
-   Note the differences between kernels with the old PCI BIOS interface and
-   newer kernels with the real PCI interface. In compat.h some things are
-   defined to make the transition easier. */
-int ali15x3_setup(void)
+int ali15x3_setup(struct pci_dev *ALI15X3_dev)
 {
 	u16 a;
 	unsigned char temp;
 
-	struct pci_dev *ALI15X3_dev;
-
-	/* First check whether we can access PCI at all */
-	if (pci_present() == 0) {
-		printk("i2c-ali15x3.o: Error: No PCI-bus found!\n");
-		return -ENODEV;
-	}
-
-	/* Look for the ALI15X3, M7101 device */
-	ALI15X3_dev = NULL;
-	ALI15X3_dev = pci_find_device(PCI_VENDOR_ID_AL,
-				      PCI_DEVICE_ID_AL_M7101, ALI15X3_dev);
-	if (ALI15X3_dev == NULL) {
-		printk("i2c-ali15x3.o: Error: Can't detect ali15x3!\n");
-		return -ENODEV;
-	}
-
 /* Check the following things:
 	- SMB I/O address is initialized
 	- Device is enabled

@@ -534,12 +513,18 @@
 
 
 static struct pci_device_id ali15x3_ids[] __devinitdata = {
+	{
+	.vendor =	PCI_VENDOR_ID_AL,
+	.device =	PCI_DEVICE_ID_AL_M7101,
+	.subvendor =	PCI_ANY_ID,
+	.subdevice =	PCI_ANY_ID,
+	},
 	{ 0, }
 };
 
 static int __devinit ali15x3_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
-	if (ali15x3_setup()) {
+	if (ali15x3_setup(dev)) {
 		printk
 		    ("i2c-ali15x3.o: ALI15X3 not detected, module not inserted.\n");
 

@@ -549,6 +534,7 @@
 	sprintf(ali15x3_adapter.name, "SMBus ALI15X3 adapter at %04x",
 		ali15x3_smba);
 	i2c_add_adapter(&ali15x3_adapter);
+	return 0;
 }
 
 static void __devexit ali15x3_remove(struct pci_dev *dev)

ChangeSet 1.1107, 2003/03/13 11:15:15-08:00, [email protected]

i2c: add bus driver for Intel 801 devices

This is from the i2c CVS tree.

 drivers/i2c/busses/Kconfig    |   23 +
 drivers/i2c/busses/Makefile   |    1 
 drivers/i2c/busses/i2c-i801.c |  710 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 734 insertions(+)

diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
@@ -53,5 +53,28 @@
 	  in the lm_sensors package, which you can download at 
 	  http://www.lm-sensors.nu
 
+config I2C_I801
+	tristate "  Intel 801"
+	depends on I2C && I2C_PROC
+	help
+	  If you say yes to this option, support will be included for the Intel
+	  801 family of mainboard I2C interfaces.  Specifically, the following
+	  versions of the chipset is supported:
+	    82801AA
+	    82801AB
+	    82801BA
+	    82801CA/CAM
+	    82801DB
+
+	  This can also be built as a module which can be inserted and removed 
+	  while the kernel is running.  If you want to compile it as a module,
+	  say M here and read <file:Documentation/modules.txt>.
+
+	  The module will be called i2c-i801.
+
+	  You will also need the latest user-space utilties: you can find them
+	  in the lm_sensors package, which you can download at 
+	  http://www.lm-sensors.nu
+
 endmenu
 

diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_I2C_ALI15X3)	+= i2c-ali15x3.o
 obj-$(CONFIG_I2C_AMD756)	+= i2c-amd756.o
 obj-$(CONFIG_I2C_AMD8111)	+= i2c-amd8111.o
+obj-$(CONFIG_I2C_I801)		+= i2c-i801.o

ChangeSet 1.1108, 2003/03/13 11:38:03-08:00, [email protected]

i2c: get i2c-i801 driver to actually bind to a PCI device.

 drivers/i2c/busses/i2c-i801.c |   74 +++++++++++++++++++++---------------------
 1 files changed, 38 insertions(+), 36 deletions(-)

diff -Nru a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
@@ -128,49 +128,21 @@
 static int i801_block_transaction(union i2c_smbus_data *data,
 				  char read_write, int command);
 
+static unsigned short i801_smba;
+static struct pci_dev *I801_dev;
+static int isich4;
 
-
-
-static unsigned short i801_smba = 0;
-static struct pci_dev *I801_dev = NULL;
-static int isich4 = 0;
-
-/* Detect whether a I801 can be found, and initialize it, where necessary.
-   Note the differences between kernels with the old PCI BIOS interface and
-   newer kernels with the real PCI interface. In compat.h some things are
-   defined to make the transition easier. */
-int i801_setup(void)
+static int i801_setup(struct pci_dev *dev)
 {
 	int error_return = 0;
 	int *num = supported;
 	unsigned char temp;
 
-	/* First check whether we can access PCI at all */
-	if (pci_present() == 0) {
-		printk(KERN_WARNING "i2c-i801.o: Error: No PCI-bus found!\n");
-		error_return = -ENODEV;
-		goto END;
-	}
-
-	/* Look for each chip */
 	/* Note: we keep on searching until we have found 'function 3' */
-	I801_dev = NULL;
-	do {
-		if((I801_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
-					      *num, I801_dev))) {
-			if(PCI_FUNC(I801_dev->devfn) != 3)
-				continue;
-			break;
-		}
-		num++;
-	} while (*num != 0);
+	if(PCI_FUNC(dev->devfn) != 3)
+		return -ENODEV;
 
-	if (I801_dev == NULL) {
-		printk
-		    (KERN_WARNING "i2c-i801.o: Error: Can't detect I801, function 3!\n");
-		error_return = -ENODEV;
-		goto END;
-	}
+	I801_dev = dev;
 	isich4 = *num == PCI_DEVICE_ID_INTEL_82801DB_SMBUS;
 
 /* Determine the address of the SMBus areas */

@@ -658,13 +630,43 @@
 
 
 static struct pci_device_id i801_ids[] __devinitdata = {
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82801AA_3,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82801AB_3,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82801BA_2,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82801CA_SMBUS,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82801DB_SMBUS,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+	},
 	{ 0, }
 };
 
 static int __devinit i801_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
 
-	if (i801_setup()) {
+	if (i801_setup(dev)) {
 		printk
 		    (KERN_WARNING "i2c-i801.o: I801 not detected, module not inserted.\n");
 		return -ENODEV;

ChangeSet 1.1109, 2003/03/13 11:52:26-08:00, [email protected]

i2c: add bus driver for Intel PIIX4 devices

This is from the i2c CVS tree.

 drivers/i2c/busses/Kconfig     |   25 +
 drivers/i2c/busses/Makefile    |    1 
 drivers/i2c/busses/i2c-piix4.c |  529 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 554 insertions(+), 1 deletion(-)

diff -Nru a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
@@ -55,7 +55,7 @@
 
 config I2C_I801
 	tristate "  Intel 801"
-	depends on I2C && I2C_PROC
+	depends on I2C && I2C_PROC && PCI && EXPERIMENTAL
 	help
 	  If you say yes to this option, support will be included for the Intel
 	  801 family of mainboard I2C interfaces.  Specifically, the following

@@ -71,6 +71,29 @@
 	  say M here and read <file:Documentation/modules.txt>.
 
 	  The module will be called i2c-i801.
+
+	  You will also need the latest user-space utilties: you can find them
+	  in the lm_sensors package, which you can download at 
+	  http://www.lm-sensors.nu
+
+config I2C_PIIX4
+	tristate "  Intel PIIX4"
+	depends on I2C && I2C_PROC && PCI && EXPERIMENTAL
+	help
+	  If you say yes to this option, support will be included for the Intel
+	  PIIX4 family of mainboard I2C interfaces.  Specifically, the following
+	  versions of the chipset is supported:
+	    Intel PIIX4
+	    Intel 440MX
+	    Serverworks OSB4
+	    Serverworks CSB5
+	    SMSC Victory66
+
+	  This can also be built as a module which can be inserted and removed 
+	  while the kernel is running.  If you want to compile it as a module,
+	  say M here and read <file:Documentation/modules.txt>.
+
+	  The module will be called i2c-piix4.
 
 	  You will also need the latest user-space utilties: you can find them
 	  in the lm_sensors package, which you can download at 

diff -Nru a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
@@ -6,3 +6,4 @@
 obj-$(CONFIG_I2C_AMD756)	+= i2c-amd756.o
 obj-$(CONFIG_I2C_AMD8111)	+= i2c-amd8111.o
 obj-$(CONFIG_I2C_I801)		+= i2c-i801.o
+obj-$(CONFIG_I2C_PIIX4)		+= i2c-piix4.o

ChangeSet 1.1110, 2003/03/13 11:59:13-08:00, [email protected]

i2c: get i2c-piix4 driver to actually bind to a PCI device.

 drivers/i2c/busses/i2c-piix4.c |   99 +++++++++++++++++++++--------------------
 1 files changed, 52 insertions(+), 47 deletions(-)

diff -Nru a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
@@ -49,18 +49,6 @@
 	const char *name;
 };
 
-/* Note: We assume all devices are identical
-         to the Intel PIIX4; we only mention it during detection.   */
-
-static struct sd supported[] = {
-	{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3, 3, "PIIX4"},
-	{PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_OSB4, 0, "OSB4"},
-	{PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_CSB5, 0, "CSB5"},
-	{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443MX_3, 3, "440MX"},
-	{PCI_VENDOR_ID_EFAR, PCI_DEVICE_ID_EFAR_SLC90E66_3, 0, "Victory66"},
-	{0, 0, 0, NULL}
-};
-
 /* PIIX4 SMBus address offsets */
 #define SMBHSTSTS (0 + piix4_smba)
 #define SMBHSLVSTS (1 + piix4_smba)

@@ -142,41 +130,16 @@
 }
 #endif
 
-/* Detect whether a PIIX4 can be found, and initialize it, where necessary.
-   Note the differences between kernels with the old PCI BIOS interface and
-   newer kernels with the real PCI interface. In compat.h some things are
-   defined to make the transition easier. */
-int piix4_setup(void)
+static int piix4_setup(struct pci_dev *PIIX4_dev, const struct pci_device_id *id)
 {
 	int error_return = 0;
 	unsigned char temp;
-	struct sd *num = supported;
-	struct pci_dev *PIIX4_dev = NULL;
 
-	if (pci_present() == 0) {
-		error_return = -ENODEV;
-		goto END;
-	}
+	/* match up the function */
+	if (PCI_FUNC(PIIX4_dev->devfn) != id->driver_data)
+		return -ENODEV;
 
-	/* Look for a supported device/function */
-	do {
-		if((PIIX4_dev = pci_find_device(num->mfr, num->dev,
-					        PIIX4_dev))) {
-			if(PCI_FUNC(PIIX4_dev->devfn) != num->fn)
-				continue;
-			break;
-		}
-		PIIX4_dev = NULL;
-		num++;
-	} while (num->mfr);
-
-	if (PIIX4_dev == NULL) {
-		printk
-		  (KERN_ERR "i2c-piix4.o: Error: Can't detect PIIX4 or compatible device!\n");
-		 error_return = -ENODEV;
-		 goto END;
-	}
-	printk(KERN_INFO "i2c-piix4.o: Found %s device\n", num->name);
+	printk(KERN_INFO "i2c-piix4.o: Found %s device\n", PIIX4_dev->dev.name);
 
 #ifdef CONFIG_X86
 	if(ibm_dmi_probe()) {

@@ -267,14 +230,14 @@
 
 
 /* Internally used pause function */
-void piix4_do_pause(unsigned int amount)
+static void piix4_do_pause(unsigned int amount)
 {
 	current->state = TASK_INTERRUPTIBLE;
 	schedule_timeout(amount);
 }
 
 /* Another internally used function */
-int piix4_transaction(void)
+static int piix4_transaction(void)
 {
 	int temp;
 	int result = 0;

@@ -363,7 +326,7 @@
 }
 
 /* Return -1 on error. */
-s32 piix4_access(struct i2c_adapter * adap, u16 addr,
+static s32 piix4_access(struct i2c_adapter * adap, u16 addr,
 		 unsigned short flags, char read_write,
 		 u8 command, int size, union i2c_smbus_data * data)
 {

@@ -456,7 +419,7 @@
 }
 
 
-u32 piix4_func(struct i2c_adapter *adapter)
+static u32 piix4_func(struct i2c_adapter *adapter)
 {
 	return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
 	    I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA |

@@ -480,16 +443,58 @@
 
 
 static struct pci_device_id piix4_ids[] __devinitdata = {
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82371AB_3,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+		.driver_data =	3
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_SERVERWORKS,
+		.device =	PCI_DEVICE_ID_SERVERWORKS_OSB4,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+		.driver_data =	0,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_SERVERWORKS,
+		.device =	PCI_DEVICE_ID_SERVERWORKS_CSB5,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+		.driver_data =	0,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_INTEL,
+		.device =	PCI_DEVICE_ID_INTEL_82443MX_3,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+		.driver_data =	3,
+	},
+	{
+		.vendor =	PCI_VENDOR_ID_EFAR,
+		.device =	PCI_DEVICE_ID_EFAR_SLC90E66_3,
+		.subvendor =	PCI_ANY_ID,
+		.subdevice =	PCI_ANY_ID,
+		.driver_data =	0,
+	},
 	{ 0, }
 };
 
 static int __devinit piix4_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
+	int retval;
+	
+	retval = piix4_setup(dev, id);
+	if (retval)
+		return retval;
 
 	sprintf(piix4_adapter.name, "SMBus PIIX4 adapter at %04x",
 		piix4_smba);
 
-	i2c_add_adapter(&piix4_adapter);
+	retval = i2c_add_adapter(&piix4_adapter);
+
+	return retval;
 }
 
 static void __devexit piix4_remove(struct pci_dev *dev)

ChangeSet 1.1111, 2003/03/13 12:16:52-08:00, [email protected]

i2c: i2c-piix4.c: Clean up the ibm dma scan logic

Also export the is_unsafe_smbus variable, which is needed.

 arch/i386/kernel/dmi_scan.c    |    3 +++
 drivers/i2c/busses/i2c-piix4.c |   20 ++------------------
 2 files changed, 5 insertions(+), 18 deletions(-)

diff -Nru a/arch/i386/kernel/dmi_scan.c b/arch/i386/kernel/dmi_scan.c
@@ -3,6 +3,7 @@
 #include <linux/kernel.h>
 #include <linux/string.h>
 #include <linux/init.h>
+#include <linux/module.h>
 #include <linux/apm_bios.h>
 #include <linux/slab.h>
 #include <asm/io.h>

@@ -893,3 +894,5 @@
 	if(err == 0)
 		dmi_check_blacklist();
 }
+
+EXPORT_SYMBOL(is_unsafe_smbus);

diff -Nru a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
@@ -28,7 +28,6 @@
    Note: we assume there can only be one device, with one SMBus interface.
 */
 
-#include <linux/version.h>
 #include <linux/module.h>
 #include <linux/config.h>
 #include <linux/pci.h>

@@ -104,31 +103,18 @@
 
 static unsigned short piix4_smba = 0;
 
-#ifdef CONFIG_X86
 /*
  * Get DMI information.
  */
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,34)
-void dmi_scan_mach(void);
-#endif
-
-static int __init ibm_dmi_probe(void)
+static int ibm_dmi_probe(void)
 {
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,34)
+#ifdef CONFIG_X86
 	extern int is_unsafe_smbus;
 	return is_unsafe_smbus;
 #else
-#define IBM_SIGNATURE		"IBM"
-	dmi_scan_mach();
-	if(dmi_ident[DMI_SYS_VENDOR] == NULL)
-		return 0;
-	if(strncmp(dmi_ident[DMI_SYS_VENDOR], IBM_SIGNATURE,
-	           strlen(IBM_SIGNATURE)) == 0)
-		return 1;
 	return 0;
 #endif
 }
-#endif
 
 static int piix4_setup(struct pci_dev *PIIX4_dev, const struct pci_device_id *id)
 {

@@ -141,7 +127,6 @@
 
 	printk(KERN_INFO "i2c-piix4.o: Found %s device\n", PIIX4_dev->dev.name);
 
-#ifdef CONFIG_X86
 	if(ibm_dmi_probe()) {
 		printk
 		  (KERN_ERR "i2c-piix4.o: IBM Laptop detected; this module may corrupt\n");

@@ -150,7 +135,6 @@
 		 error_return = -EPERM;
 		 goto END;
 	}
-#endif
 
 /* Determine the address of the SMBus areas */
 	if (force_addr) {

ChangeSet 1.1112, 2003/03/13 12:26:39-08:00, [email protected]

i2c: add i2c sysfs bus support.

 drivers/i2c/i2c-core.c |   33 ++++++++++++++++++++++++++++++---
 include/linux/i2c.h    |    3 +++
 2 files changed, 33 insertions(+), 3 deletions(-)

diff -Nru a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
@@ -598,10 +598,37 @@
 {
 	remove_proc_entry("i2c",proc_bus);
 }
+#else
+static int __init i2cproc_init(void) { return 0; }
+static void __exit i2cproc_cleanup(void) { }
+#endif /* CONFIG_PROC_FS */
 
-module_init(i2cproc_init);
-module_exit(i2cproc_cleanup);
-#endif /* def CONFIG_PROC_FS */
+/* match always succeeds, as we want the probe() to tell if we really accept this match */
+static int i2c_device_match(struct device *dev, struct device_driver *drv)
+{
+	return 1;
+}
+
+struct bus_type i2c_bus_type = {
+	.name =		"i2c",
+	.match =	i2c_device_match,
+};
+
+
+static int __init i2c_init(void)
+{
+	bus_register(&i2c_bus_type);
+	return i2cproc_init();
+}
+
+static void __exit i2c_exit(void)
+{
+	i2cproc_cleanup();
+	bus_unregister(&i2c_bus_type);
+}
+
+module_init(i2c_init);
+module_exit(i2c_exit);
 
 /* ----------------------------------------------------
  * the functional interface to the i2c busses.

diff -Nru a/include/linux/i2c.h b/include/linux/i2c.h
@@ -34,6 +34,7 @@
 #include <linux/module.h>
 #include <linux/types.h>
 #include <linux/i2c-id.h>
+#include <linux/device.h>	/* for struct device */
 #include <asm/semaphore.h>
 
 /* --- General options ------------------------------------------------	*/

@@ -143,6 +144,8 @@
 	 */
 	int (*command)(struct i2c_client *client,unsigned int cmd, void *arg);
 };
+
+extern struct bus_type i2c_bus_type;
 
 /*
  * i2c_client identifies a single device (i.e. chip) that is connected to an 

ChangeSet 1.1113, 2003/03/13 16:37:27-08:00, [email protected]

driver core: Export the legacy_bus structure for drivers to use.

 drivers/base/platform.c |    3 ++-
 include/linux/device.h  |    1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff -Nru a/drivers/base/platform.c b/drivers/base/platform.c
@@ -9,7 +9,7 @@
 #include <linux/module.h>
 #include <linux/init.h>
 
-static struct device legacy_bus = {
+struct device legacy_bus = {
 	.name		= "legacy bus",
 	.bus_id		= "legacy",
 };

@@ -75,5 +75,6 @@
 	return bus_register(&platform_bus_type);
 }
 
+EXPORT_SYMBOL(legacy_bus);
 EXPORT_SYMBOL(platform_device_register);
 EXPORT_SYMBOL(platform_device_unregister);

diff -Nru a/include/linux/device.h b/include/linux/device.h
@@ -366,6 +366,7 @@
 extern void platform_device_unregister(struct platform_device *);
 
 extern struct bus_type platform_bus_type;
+extern struct device legacy_bus;
 
 /* drivers/base/power.c */
 extern int device_suspend(u32 state, u32 level);

ChangeSet 1.1114, 2003/03/13 16:39:40-08:00, [email protected]

i2c: add driver model support to i2c adapter drivers

 drivers/i2c/busses/i2c-ali15x3.c |    6 ++++--
 drivers/i2c/busses/i2c-amd756.c  |    3 +++
 drivers/i2c/busses/i2c-amd8111.c |    5 ++++-
 drivers/i2c/busses/i2c-i801.c    |    5 ++++-
 drivers/i2c/busses/i2c-piix4.c   |    3 +++
 drivers/i2c/i2c-core.c           |   13 +++++++++++++
 include/linux/i2c.h              |    2 ++
 7 files changed, 33 insertions(+), 4 deletions(-)

diff -Nru a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
@@ -531,10 +531,12 @@
 		return -ENODEV;
 	}
 
+	/* set up the driverfs linkage to our parent device */
+	ali15x3_adapter.dev.parent = &dev->dev;
+
 	sprintf(ali15x3_adapter.name, "SMBus ALI15X3 adapter at %04x",
 		ali15x3_smba);
-	i2c_add_adapter(&ali15x3_adapter);
-	return 0;
+	return i2c_add_adapter(&ali15x3_adapter);
 }
 
 static void __devexit ali15x3_remove(struct pci_dev *dev)

diff -Nru a/drivers/i2c/busses/i2c-amd756.c b/drivers/i2c/busses/i2c-amd756.c
@@ -375,6 +375,9 @@
 	printk(KERN_DEBUG DRV_NAME ": AMD756_smba = 0x%X\n", amd756_ioport);
 #endif
 
+	/* set up the driverfs linkage to our parent device */
+	amd756_adapter.dev.parent = &pdev->dev;
+
 	sprintf(amd756_adapter.name,
 		"SMBus AMD75x adapter at %04x", amd756_ioport);
 

diff -Nru a/drivers/i2c/busses/i2c-amd8111.c b/drivers/i2c/busses/i2c-amd8111.c
@@ -363,6 +363,9 @@
 	smbus->adapter.algo = &smbus_algorithm;
 	smbus->adapter.algo_data = smbus;
 
+	/* set up the driverfs linkage to our parent device */
+	smbus->adapter.dev.parent = &dev->dev;
+
 	error = i2c_add_adapter(&smbus->adapter);
 	if (error)
 		goto out_release_region;

@@ -389,7 +392,7 @@
 }
 
 static struct pci_driver amd8111_driver = {
-	.name		= "amd8111 smbus 2.0",
+	.name		= "amd8111 smbus",
 	.id_table	= amd8111_ids,
 	.probe		= amd8111_probe,
 	.remove		= __devexit_p(amd8111_remove),

diff -Nru a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
@@ -672,9 +672,12 @@
 		return -ENODEV;
 	}
 
+	/* set up the driverfs linkage to our parent device */
+	i801_adapter.dev.parent = &dev->dev;
+
 	sprintf(i801_adapter.name, "SMBus I801 adapter at %04x",
 		i801_smba);
-	i2c_add_adapter(&i801_adapter);
+	return i2c_add_adapter(&i801_adapter);
 }
 
 static void __devexit i801_remove(struct pci_dev *dev)

diff -Nru a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
@@ -473,6 +473,9 @@
 	if (retval)
 		return retval;
 
+	/* set up the driverfs linkage to our parent device */
+	piix4_adapter.dev.parent = &dev->dev;
+
 	sprintf(piix4_adapter.name, "SMBus PIIX4 adapter at %04x",
 		piix4_smba);
 

diff -Nru a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
@@ -87,6 +87,16 @@
 	init_MUTEX(&adap->bus);
 	init_MUTEX(&adap->list);
 
+	/* Add the adapter to the driver core.
+	 * If the parent pointer is not set up,
+	 * we add this adapter to the legacy bus.
+	 */
+	if (adap->dev.parent == NULL)
+		adap->dev.parent = &legacy_bus;
+	sprintf(adap->dev.bus_id, "i2c-%d", i);
+	strcpy(adap->dev.name, "i2c controller");
+	device_register(&adap->dev);
+
 	/* inform drivers of new adapters */
 	for (j=0;j<I2C_DRIVER_MAX;j++)
 		if (drivers[j]!=NULL && 

@@ -153,6 +163,9 @@
 	}
 
 	i2cproc_remove(i);
+
+	/* clean up the sysfs representation */
+	device_unregister(&adap->dev);
 
 	adapters[i] = NULL;
 

diff -Nru a/include/linux/i2c.h b/include/linux/i2c.h
@@ -231,12 +231,14 @@
 
 	int timeout;
 	int retries;
+	struct device dev;	/* the adapter device */
 
 #ifdef CONFIG_PROC_FS 
 	/* No need to set this when you initialize the adapter          */
 	int inode;
 #endif /* def CONFIG_PROC_FS */
 };
+#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)
 
 /*flags for the driver struct: */
 #define I2C_DF_NOTIFY	0x01		/* notify on bus (de/a)ttaches 	*/

Ah, I removed the "2.0" portion because it was larger than the 16 character limit for pci driver names (it shows up in sysfs garbled if it's bigger).

Would "amd8111 smbus 2" be an ok name?

thanks,

greg k-h

Yes.

Vojtech Pavlik
SuSE Labs

Thanks.

So where should I be looking to get the latest kernel code? It looks like the kernel files in drivers/i2c/ are in the i2c CVS's kernel/ directory, right?

And then the kernel drivers/i2c/busses/ and drivers/i2c/chips match up with the lm_sensors2 CVS's kernel/busses and kernel/chips directories?

If so, any hope of merging the two to make it at least sane? :)

Where are these drivers? I only see 17 instances of pci_module_init() in the lm_sensors2 cvs tree. Are these the ones? If you look at 2.5.65, 3 ones were added from the cvs tree (and converted to work properly with the pci code.) I see there are only 5 drivers in the main kernel tree that use pci_module_init() so a number more still need to be moved into there.

Why care about backwards compatibility? Hopefully there will not need to be a cvs tree for the kernel portions of the i2c code if we get all of the code into the main kernel tree.

It's tough to develop code in a cvs tree and then move that into the main kernel tree (trust me, I've done it for years...) It's much easier once the code is in the main kernel, to just work off of those versions, possibly keeping a few patches along as they are developed, before they are accepted in the main kernel trees. I've successfully done this for the pci hotplug code for 2.4 and 2.5, and the usb code for 2.2, 2.4, and 2.5.

Also, kernel code over kernel major versions differs a lot. Already the i2c code is branched due to the driver model changes, and that will also cause more changes in the future (all good :)

Are there any test scripts or procedures that one should go through to determine if any changes break anything or not?

thanks,

greg k-h

True, but it seems strange to have files in two different repositories. But I now see why you did that because of the 2.4 code, right? Anyway, I'll live :)

Good, I haven't really looked at them yet.

You've already forked the cvs tree, right? What's keeping you from just staying with this fork for the 2.4 code?

I'm not so sure about that due to the driver model changes, but am not certain yet. I'll shut up now until I get some more code done...

thanks,

greg k-h

With Greg's driver model changes the code won't compile under 2.4 anymore. But I think it might be possible to supply stubs for that functionality so that the drivers can be used on 2.4 aswell.

Submitting out of CVS is bad, this leads to the usualy "CVS mentality" with resyncs instead of properly one thing at a time changes.

What do you think about having them in 2.5 first and then put them into CVS for the 2.4 backport (which in the best case is not a port at all but just the addition of a compatiblity header).

I'm happy to help out with feeding the sensors changes to Linus and review / fix smaller issues.

Ah, that makes more sense now, thanks for the history lesson.

Converting the i2c core, and all drivers over to the kernel driver model. See include/linux/device.h for the structures and Documentation/driver-model/* for lots of documentation. Also, Pat Mochel has written a lot of good documentation at:
http://www.kernel.org/pub/linux/kernel/people/mochel/doc/lca/driver-model-lca2003.tar.gz

It basically involves hooking the drivers and core up to the rest of the kernel, like I've already done. All of the kernel's drivers are either already converted to this model, or are in the process of being converted.

For now, yes.

Not yet. If you look at my original patch I sent to the list, I do hook up the chip drivers to the driver core, but don't do much with them. I didn't include that portion in my patches to Linus as it needs some more work to get everything working properly.

Does this help explain stuff? I hope to have a more concrete set of patches soon to show what I'm talking about (code is sometimes easier to understand than documentation :)

thanks,

greg k-h

Actually, I read the CVS docs some days ago, and there seem to be a command for that. See there:
http://www.cvshome.org/docs/manual/cvs_7.html#SEC70

OK, doesn't sound easy, but not impossible. What about using method 1 (7.4.1 in the docs) and simply add some header comment in the new file stating the old name, so that one can get the history if needed?

(...)

I really think we shouldn't give our preference to compatibility over code cleanness. We could simply keep 2.7.0 as our pre-heavy-work release, and do the minimum bugfixes to it when required, no more. Once "everything" is integrated into the kernel (and you have gone too far already for this not to happen), nobody will care about the old code anymore, so I don't think it's clever to spend too many time on it.

Just my opinion, though.

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

Greg,

I'm catching up on my mail. Glad to have you on the job. It's good you are taking things from CVS.
As you may know, Kyosti Malkki did a lot of cleanup and pre-2.4.9 compatiblility removal in January.
He branched i2c CVS (with the HEAD 2.5-compatible). Lm_sensors CVS is not branched.

The biggest thing remaining to do in CVS is tackling the PCI drivers. Approx. 20 of our 60 drivers are PCI.

I'd like to keep sensors CVS 2.4-compatible, or at least delay a branch as long as possible. Kyosti was working on getting to the point that we could submit a patch to 2.4 (until we do that, CVS is incompatible with stock 2.4 kernels because of the i2c_driver struct change). Any sensors changes/cleanups that are 2.4 compatible, it's preferable to check those changes into CVS for testing. Ideally we can submit drivers to 2.5 directly out of CVS.

mds

right

right

sounds like more trouble than it is worth; hard to move files in CVS without losing the history.

right. Plus a couple more in chips/ that don't call pci_module_init (sis5595, vt8231). Minus the ones already in 2.5 (I see that 2.5.65 added your patch with 3 more) leaves about 15.

My point was the ~40 non-PCI drivers should go a lot more easily; Kyosti already did a lot of cleanup on those.

We have a large number of 2.4-based "customers". Our project is ranked in the top 100 on freshmeat (no idea if that means anything, though :) If our 2.7.0 release last December was the last 2.4-compatible release, how bad is that? I don't know. Unless we get a patch into 2.4, it will be, because of the i2c_driver struct change that's already been made in CVS. I'm guessing we want to release 2.4-compatible packages for another year? But maybe that's hopelessly ambitious. Maybe 2.7.0 will have to be it. Kyosti was optimistic that on the lm_sensors side (as opposed to i2c), we could stay compatible with 2.4 and 2.5 in one branch. But he hasn't been heard from in a while...

I'm not disagreeing with you. Maybe it's easier with our collection of small drivers. Maybe not. Maybe it only makes sense for drivers not yet in the kernel.

Nothing formal.
You can send the group mail and ask for testing. I have a pretty good collection of HW. For bus drivers, if you're lucky enough to have HW to test on,
you should try i2cdetect, and i2cdump (with different modes).
For chip drivers, even if you don't have the hardware, it's
good to load the module with a force_xxx parameter and
then try 'sensors' and look in /proc.

No. The i2c and sensors projects were started by different people in different places. In 1999, the i2c project was moved to be hosted at Netroedge, where the sensors project was already.
It was put in a separate CVS tree. Over the last couple of years the original i2c contributors have moved on.
But the separate trees remain.

guess I missed something, exactly what are the "driver model changes"? I see a new adapter.dev.parent in the bus drivers, is that it? Are there any changes affecting the chip drivers? I didn't see any.

thanks for the driver model links, that's what I needed.

static..

OOPS, should take a look at all patches first before complaining :)

Heh :)

Yes, for the first changeset I just took the cvs version of the driver and added it.

Then I went and made the driver work, and started to clean it up. These drivers still need a lot of cleanup (static, printk, indentation in places, etc.) and I'll be doing it. This is a work in progress. I wanted to make baby steps with these things and not just do one changeset with a description that said:
Took cvs version of driver and cleaned up everything

I'm trying to bridge the gap between the sensor developers and the kernel group. Hopefully by working this way it will help integrate them more into the kernel community, and get these drivers whipped into shape.

thanks for looking these over.

greg k-h

Should be static like everything in this file (and merged into ali15x3_probe anyway).

I'll move this. I think I have this in the usb.h header file too :)

In the next round of patches I'm using dev_dbg() and other dev_* functions for the printk calls, now that we have device support for the adapters.

thanks,

greg k-h