Skip to contentSkip to conversation

Moving to new driver model: probe never called

DISCUSSION Shane Dixon 2 participants 4 messages May 1, 2009 – May 4, 2009 1 message not in the archive I2C subsystem host drivers

lore
Share & tools
lore
#0 lore raw

I'm trying to port a working driver from the old device driver model to the new. I have a printk in the first line of my probe function, which never gets printed after doing a modprobe. Hooking up a scope shows that nothing is sent at all to the device. Below is the relevant snippets of code:

#define DEVICE_NAME "atpm"

static struct i2c_device_id atpm_idtable[] = {
{ DEVICE_NAME, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, atpm_idtable);

static struct i2c_driver atpm_driver =
{
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
},
.probe = atpm_probe,
.remove = __devexit_p(atpm_remove),
.id_table = atpm_idtable,
.detect = atpm_detect,
/* .address_data = &addr_data */
};

static int __init atpm_init(void)
{
printk(DEVICE_NAME ": adding i2c driver\n");
return i2c_add_driver(&atpm_driver);
}

static void __exit atpm_exit(void)
{
i2c_del_driver(&atpm_driver);
printk(DEVICE_NAME ": deleting i2c driver\n");
}

module_init(atpm_init);
module_exit(atpm_exit);

Any help would be appreciated.

Signature · 4 lines
Shane Dixon
Linux Engineer
Atmel Corporation
E-mail: [email protected]
#1 lore raw

Hi Shane,

Quoted 14 lines · Shane Dixon

I'm trying to port a working driver from the old device driver model to the new. I have a printk in the first line of my probe function, which never gets printed after doing a modprobe. Hooking up a scope shows that nothing is sent at all to the device. Below is the relevant snippets of code:

#define DEVICE_NAME "atpm"

static struct i2c_device_id atpm_idtable[] = {
{ DEVICE_NAME, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, atpm_idtable);

Quoted 11 lines

static struct i2c_driver atpm_driver =
{
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
},
.probe = atpm_probe,
.remove = __devexit_p(atpm_remove),
.id_table = atpm_idtable,
.detect = atpm_detect,
/* .address_data = &addr_data */

.detect is ignored without .address_data. From i2c-core.c:

static int i2c_detect(struct i2c_adapter *adapter, struct i2c_driver *driver)

{
	const struct i2c_client_address_data *address_data;
	(...)

	address_data = driver->address_data;
	if (!driver->detect || !address_data)
		return 0;

Additionally, you must define atpm_driver.class, otherwise atpm_driver.detect will never be called.

Quoted 14 lines

};

static int __init atpm_init(void)
{
printk(DEVICE_NAME ": adding i2c driver\n");
return i2c_add_driver(&atpm_driver);
}

static void __exit atpm_exit(void)
{
i2c_del_driver(&atpm_driver);
printk(DEVICE_NAME ": deleting i2c driver\n");
}

Quoted 4 lines

module_init(atpm_init);
module_exit(atpm_exit);

Any help would be appreciated.

What is this "atpm" device? Can it be reliably detected? In general it is better to instantiate I2C devices explicitly, for example through platform data. Why don't you do that?

Signature · 2 lines
Jean Delvare
http://khali.linux-fr.org/wishlist.html

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw

Jean,

Thank you for the help. This is only my 2nd driver I've ever written (the first one being the i2c legacy version of the same driver!) I think that did it. The device is a tpm, but the I2C_CLASS_HWMON seems to help it get a little farther to the detect function. I also had to make sure I had the normal_i2c[] struct present because I know the device listens on 0x29. This isn't something I can modify the board_info for because it's just wires jumping the device over to a development board (for a demo), so it's not permanently soldered on. I don't think it would be correct to use the board_info to treat it like a static device.

--
Shane

Quoted 66 lines · Jean Delvare

Hi Shane,

Quoted 14 lines · Shane Dixon

I'm trying to port a working driver from the old device driver model to the new. I have a printk in the first line of my probe function, which never gets printed after doing a modprobe. Hooking up a scope shows that nothing is sent at all to the device. Below is the relevant snippets of code:

#define DEVICE_NAME "atpm"

static struct i2c_device_id atpm_idtable[] = {
{ DEVICE_NAME, 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, atpm_idtable);

Quoted 11 lines

static struct i2c_driver atpm_driver =
{
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
},
.probe = atpm_probe,
.remove = __devexit_p(atpm_remove),
.id_table = atpm_idtable,
.detect = atpm_detect,
/* .address_data = &addr_data */

.detect is ignored without .address_data. From i2c-core.c:

static int i2c_detect(struct i2c_adapter *adapter, struct i2c_driver *driver)

{
	const struct i2c_client_address_data *address_data;
	(...)

	address_data = driver->address_data;
	if (!driver->detect || !address_data)
		return 0;

Additionally, you must define atpm_driver.class, otherwise atpm_driver.detect will never be called.

Quoted 14 lines

};

static int __init atpm_init(void)
{
printk(DEVICE_NAME ": adding i2c driver\n");
return i2c_add_driver(&atpm_driver);
}

static void __exit atpm_exit(void)
{
i2c_del_driver(&atpm_driver);
printk(DEVICE_NAME ": deleting i2c driver\n");
}

Quoted 4 lines

module_init(atpm_init);
module_exit(atpm_exit);

Any help would be appreciated.

What is this "atpm" device? Can it be reliably detected? In general it is better to instantiate I2C devices explicitly, for example through platform data. Why don't you do that?

Signature · 4 lines
Shane Dixon
Linux Engineer
Atmel Corporation
E-mail: [email protected]
#4 lore raw

Hi Shane,

Quoted 4 lines · Shane Dixon

Thank you for the help. This is only my 2nd driver I've ever written (the first one being the i2c legacy version of the same driver!) I think that did it. The device is a tpm, but the I2C_CLASS_HWMON seems to help it get a little farther to the detect function.

Might be acceptable for your local testing, but obviously not for upstream submission.

Quoted 7 lines

I also had to
make sure I had the normal_i2c[] struct present because I know the device listens on 0x29. This isn't something I can modify the board_info for because it's just wires jumping the device over to a development board (for a demo), so it's not permanently soldered on. I don't think it would be correct to use the board_info to treat it like a static device.

OK, that makes sense. I have just added a sysfs interface to handle this situation more gracefully. I'll Cc you when I post it (in a minute), please give it a try if you can.

Signature · 2 lines
Jean Delvare
http://khali.linux-fr.org/wishlist.html