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.
