I2C node in device tree breaks old-style drivers

I'm trying to debug an I2C problem I've found in my old-style driver:
sound/soc/codecs/cs4270.c. My I2C probe function is working, but the I2C subsystem cannot find my device. I know it's there, because U-Boot can probe it just fine.

At first, I thought my problem was this:

static struct i2c_driver cs4270_i2c_driver = {
	.driver = {
		.name = "CS4270 I2C",
		.owner = THIS_MODULE,
	},
	.id =             I2C_DRIVERID_CS4270,
	.attach_adapter = cs4270_i2c_attach,
	.detach_client =  cs4270_i2c_detach,
};

In a slightly older kernel (still 2.6.27), I had to change "CS4270 I2C" to "cs4270" to get it to work. However, that change no longer makes a difference.

I turned on debugging and this is what I see:

i2c-core: driver [CS4270 I2C] registered
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x48 i2c-adapter i2c-0: master_xfer[0] W, addr=0x48, len=0 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x49 i2c-adapter i2c-0: master_xfer[0] W, addr=0x49, len=0 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4a i2c-adapter i2c-0: master_xfer[0] W, addr=0x4a, len=0 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4b i2c-adapter i2c-0: master_xfer[0] W, addr=0x4b, len=0 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4c i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=0 i2c-adapter i2c-0: master_xfer[0] W, addr=0x4c, len=1 i2c-adapter i2c-0: master_xfer[1] R, addr=0x4c, len=1 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4d i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=0 i2c-adapter i2c-0: master_xfer[0] W, addr=0x4d, len=1 i2c-adapter i2c-0: master_xfer[1] R, addr=0x4d, len=1 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4e i2c-adapter i2c-0: master_xfer[0] W, addr=0x4e, len=0 i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x4f

My device is at address 4F. The device tree defines a node for this device. You can see it in arch/powerpc/boot/dts/mpc8610_hpcd.dts.

When I change the device tree so that it lists the device at an address other than 4F, (e.g. "reg = <0x48>"), then my driver works.

So my conclusion is that specifying an I2C node in the device tree *requires* that the driver be new-style. Is there any way we can fix this? I'm not going to have time to update the CS4270 driver to a new-style interface before the 2.6.27 window closes.

Timur Tabi
Linux kernel developer at Freescale

Hi Timur,

This conclusion is correct. One possible way to fix this is to add support for blacklisting to drivers/of/base.c (untested):

[RFC] of: Support blacklisting and blacklist cs4270.

---
 drivers/of/base.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

index ad8ac1a..8c53b2c 100644
@@ -404,13 +404,16 @@ EXPORT_SYMBOL(of_find_matching_node);
  * assumed that the data size is small and that the compatible values
  * should already be distinct enough to differentiate between SPI, I2C
  * and other devices.
+ *
+ * Blacklisting devices is supported by using NULL as modalias.
  */
 struct of_modalias_table {
 	char *of_device;
 	char *modalias;
 };
 static struct of_modalias_table of_modalias_table[] = {
-	/* Empty for now; add entries as needed */
+	/* Blacklisting cs4270 as this driver is currently old-style. */
+	{ "cirrus,cs4270",	NULL }
 };
 
 /**

@@ -441,6 +444,9 @@ int of_modalias_node(struct device_node *node, char *modalias, int len)
 		compatible = of_modalias_table[i].of_device;
 		if (!of_device_is_compatible(node, compatible))
 			continue;
+		/* Check for blacklisting */
+		if (!of_modalias_table[i].modalias)
+			return -ENODEV;
 		strlcpy(modalias, of_modalias_table[i].modalias, len);
 		return 0;
 	}

1.5.6.3

No need. I posted a patch to alsa-devel that makes the CS4270 a new-style I2C driver. I'd hate to think that my driver is the only I2C driver used on PowerPC systems that was outdated. :-)

Timur Tabi
Linux kernel developer at Freescale