usage of driver_data member of I2C device id table

i2c, linux-device-driver

Solution

1) The definition of `i2c_device_id` structure contains two members (`name`, `driver_data`). The 1st member (`name`) is used to define the device name which will be used during driver binding, what is the use of the 2nd member (`driver_data`).

First you define the table (array) of `i2c_device_id` structures, like it's done in max732x.c driver:

static const struct i2c_device_id max732x_id[] = {
    { "max7319", 0 },
    { "max7320", 1 },
    { "max7321", 2 },
    { },
};
MODULE_DEVICE_TABLE(i2c, max732x_id);

In your driver probe function you have one element of this array (for your particular device) as second parameter:

static int max732x_probe(struct i2c_client *client,
                         const struct i2c_device_id *id)

Now you can use `id->driver_data` (which is unique to each device from the table) for your own purposes. E.g. for "max7320" chip `driver_data` will be `1`.

For example, if you have features which are specific to each device, you can create the array of features like this:

static uint64_t max732x_features[] = {
    [0] = FEATURE0,
    [1] = FEATURE1 | FEATURE2,
    [2] = FEATURE2
};

and you can obtain features of your particular device from this array like this:

max732x_features[id->driver_data]

Of course, you can use driver name for the same reason. But it would take more code and more CPU time. So basically if you don't need `driver_data` for your driver -- you just make it `0` for all devices (in device table).

2) Driver binding will happen based on `i2c_device_id` table or device tree compatible string.

To figure this out you can take a look at `i2c_device_match()` function (for example here). As you can see, first I2C core tries to match device by `compatible` string (OF style, which is Device Tree). And if it fails, it then tries to match device by id table.

Problem

Original source