driver core support for i2c bus and drivers

RFC In review Greg KH 3 participants 7 messages Mar 10, 2003 – May 19, 2005

Subsystems (3)

I2C subsystem host drivers I2C I2C/smbus controller drivers for pc

lore

Share & tools

lore

Greg KH

author

2003-03-10 07:23 UTC #0 lore raw

RFC 1/1 driver core support for i2c bus and drivers

Hi all,

Here's a fairly small patch against 2.5.64 that adds initial driver core support for the i2c code. It only has logic for the i2c bus, i2c bus controllers, and i2c drivers, but it's a start :)

As an example, with this patch, the i2c-piix4 driver shows up in the pci bus as (other devices omitted for clarity):

[greg@desk sys]$ tree bus/pci
bus/pci/
|-- devices
| |-- 00:07.3 -> ../../../devices/pci0/00:07.3
`-- drivers

    |-- piix4 smbus
    |   `-- 00:07.3 -> ../../../../devices/pci0/00:07.3

And within that device, the first i2c bus is located:

[greg@desk sys]$ tree devices/pci0/00:07.3
devices/pci0/00:07.3

|-- i2c-0
|   |-- name
|   `-- power

And the i2c bus looks like:

[greg@desk sys]$ tree bus/i2c/
bus/i2c/
|-- devices
`-- drivers
`-- EEPROM READER

I'll move on to adding i2c device support to the core, but that will be a bit more work. Comments on this patch are appreciated.

thanks,

greg k-h

p.s. Yes, I added the i2c-piix4 and i2c-ali15x3 and i2c-i801 drivers to my kernel tree, from the i2c CVS tree, and tweaked them to actually work properly. If someone wants those patches right now, please let me know.

drivers/i2c/busses/i2c-ali15x3.c +3 -0

diff -Nru a/drivers/i2c/busses/i2c-ali15x3.c b/drivers/i2c/busses/i2c-ali15x3.c
@@ -547,6 +546,9 @@
 
 		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);

drivers/i2c/busses/i2c-amd756.c +3 -0

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

drivers/i2c/busses/i2c-amd8111.c +3 -0

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;

drivers/i2c/busses/i2c-i801.c +3 -0

diff -Nru a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
@@ -679,6 +679,9 @@
 		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);

drivers/i2c/busses/i2c-piix4.c +3 -0

diff -Nru a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
@@ -504,6 +492,9 @@
 	retval = piix4_setup(dev, id);
 	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);

drivers/i2c/i2c-core.c +65 -3

111 lines not on this page · raw message

include/linux/i2c.h +10 -1

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 ------------------------------------------------	*/

@@ -142,7 +143,12 @@
 	 * with the device.
 	 */
 	int (*command)(struct i2c_client *client,unsigned int cmd, void *arg);
+
+	struct device_driver driver;
 };
+#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
+
+extern struct bus_type i2c_bus_type;
 
 /*
  * i2c_client identifies a single device (i.e. chip) that is connected to an

@@ -164,8 +170,9 @@
 	void *data;			/* for the clients		*/
 	int usage_count;		/* How many accesses currently  */
 					/* to the client		*/
+	struct device dev;		/* the device structure		*/
 };
-
+#define to_i2c_client(d) container_of(d, struct i2c_client, dev)
 
 /*
  * The following structs are for those who like to implement new bus drivers:

@@ -228,12 +235,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 	*/

Albert Cranford

2003-03-10 21:59 UTC #1 lore raw

Quoted 37 lines · Greg KH

Hi all,
Here's a fairly small patch against 2.5.64 that adds initial driver core support for the i2c code. It only has logic for the i2c bus, i2c bus controllers, and i2c drivers, but it's a start :)
As an example, with this patch, the i2c-piix4 driver shows up in the pci bus as (other devices omitted for clarity):
[greg@desk sys]$ tree bus/pci
bus/pci/
|-- devices
| |-- 00:07.3 -> ../../../devices/pci0/00:07.3
`-- drivers
    |-- piix4 smbus
    |   `-- 00:07.3 -> ../../../../devices/pci0/00:07.3
And within that device, the first i2c bus is located:
[greg@desk sys]$ tree devices/pci0/00:07.3
devices/pci0/00:07.3
|-- i2c-0
|   |-- name
|   `-- power
And the i2c bus looks like:
[greg@desk sys]$ tree bus/i2c/
bus/i2c/
|-- devices
`-- drivers
`-- EEPROM READER
I'll move on to adding i2c device support to the core, but that will be a bit more work. Comments on this patch are appreciated.

Quoted 8 lines

thanks,
greg k-h
p.s. Yes, I added the i2c-piix4 and i2c-ali15x3 and i2c-i801 drivers to my kernel tree, from the i2c CVS tree, and tweaked them to actually work properly. If someone wants those patches right now, please let me know.

I like. The proc/bus directory was geting cluttered. I think the driver model would be a good for i2c/sensors. Do you have any input for isa already in your bag of goodies?
Albert

Signature · 2 lines

Albert Cranford Deerfield Beach FL USA
[email protected]

Greg KH

author

2003-03-10 22:12 UTC #2 lore raw

Quoted 1 line · Albert Cranford

I like. The proc/bus directory was geting cluttered.

Heh, that's an understatement :)

Quoted 1 line

I think the driver model would be a good for i2c/sensors.

It seems to fit quite nicely, and should clean up a lot of the sysctl madness that you have been forced to live with for 2.0, 2.2, and 2.4.

Quoted 2 lines

Do you have any input for isa already in your bag of goodies?

Yes, the i2c-isa driver should add itself to the sys/devices/legacy tree, I just hadn't added that patch yet, still bickering with Pat about the interface to register devices there :)

thanks,

greg k-h

Mark D. Studebaker

2005-05-19 06:23 UTC #3 lore raw

In reply to Greg KH

Greg,

our userspace tools use the /proc/bus/i2c file and (of course) the entire tree of exported sysctl info under /proc/sys/dev/sensors
(as implemented in i2c-proc.c).

Does your proposal or Cristoph's recent changes affect these?

mds

Quoted 53 lines · Albert Cranford

Quoted 36 lines · Greg KH
Hi all,
Here's a fairly small patch against 2.5.64 that adds initial driver core support for the i2c code. It only has logic for the i2c bus, i2c bus controllers, and i2c drivers, but it's a start :)
As an example, with this patch, the i2c-piix4 driver shows up in the pci bus as (other devices omitted for clarity):
[greg@desk sys]$ tree bus/pci
bus/pci/
|-- devices
| |-- 00:07.3 -> ../../../devices/pci0/00:07.3
`-- drivers
|-- piix4 smbus
| `-- 00:07.3 -> ../../../../devices/pci0/00:07.3
And within that device, the first i2c bus is located:
[greg@desk sys]$ tree devices/pci0/00:07.3
devices/pci0/00:07.3
|-- i2c-0
|   |-- name
|   `-- power
And the i2c bus looks like:
[greg@desk sys]$ tree bus/i2c/
bus/i2c/
|-- devices
`-- drivers
`-- EEPROM READER
I'll move on to adding i2c device support to the core, but that will be a bit more work. Comments on this patch are appreciated.
Quoted 8 lines
thanks,
greg k-h
p.s. Yes, I added the i2c-piix4 and i2c-ali15x3 and i2c-i801 drivers to my kernel tree, from the i2c CVS tree, and tweaked them to actually work properly. If someone wants those patches right now, please let me know.
I like. The proc/bus directory was geting cluttered. I think the driver model would be a good for i2c/sensors. Do you have any input for isa already in your bag of goodies?
Albert

Greg KH

author

2003-03-18 01:28 UTC #4 lore raw

Quoted 4 lines · Mark D. Studebaker

our userspace tools use the /proc/bus/i2c file and (of course) the entire tree of exported sysctl info under /proc/sys/dev/sensors
(as implemented in i2c-proc.c).

Right now, the /proc and sysctl code is not changed at all.

However, the end goal will be to remove the /proc and sysctl code entirely, and just use sysfs, as this is exactly what sysfs is for. I know, in order to do this properly the userspace library will need to be changed, and I'm willing to do this work too. I do not want to break userspace compatibility needlessly.

I'll not remove anything until the same functionality can be achieved, is this ok? I will, of course, provide patches that for people to evaluate, when it's working...

Quoted 1 line

Does your proposal or Cristoph's recent changes affect these?

Christoph's changes preserve the existing code, but make it work without oopses :)

thanks,

greg k-h

Greg KH

author

2005-05-19 06:23 UTC #5 lore raw

In reply to Greg KH

Quoted 2 lines · Mark D. Studebaker

The oops problem is present in CVS but not in our 2.7.0 release, correct?

I did not have a problem with that release on a 2.4 kernel, correct.

thanks,

greg k-h

Mark D. Studebaker

2005-05-19 06:23 UTC #6 lore raw

In reply to Greg KH

Sounds good. Thanks for volunteering to do the userspace changes. I can also do them. I maintain most of them in our package. (not that the changes are likely to be hard - look for a file in one place, if it isn't there, look in the next place...) Of course there are programs outside of our package that access our /proc info directly or indirectly through our libsensors library, they would get broken too.

The oops problem is present in CVS but not in our 2.7.0 release, correct?

Quoted 29 lines · Greg KH

Quoted 3 lines · Mark D. Studebaker
our userspace tools use the /proc/bus/i2c file and (of course) the entire tree of exported sysctl info under /proc/sys/dev/sensors
(as implemented in i2c-proc.c).
Right now, the /proc and sysctl code is not changed at all.
However, the end goal will be to remove the /proc and sysctl code entirely, and just use sysfs, as this is exactly what sysfs is for. I know, in order to do this properly the userspace library will need to be changed, and I'm willing to do this work too. I do not want to break userspace compatibility needlessly.
I'll not remove anything until the same functionality can be achieved, is this ok? I will, of course, provide patches that for people to evaluate, when it's working...
Quoted 1 line
Does your proposal or Cristoph's recent changes affect these?
Christoph's changes preserve the existing code, but make it work without oopses :)
thanks,
greg k-h