Почему i2c_device_id определяется отдельно, а не частью i2c_client - PullRequest
Новая
       15

Почему i2c_device_id определяется отдельно, а не частью i2c_client

0 голосов
/ 08 апреля 2019

Почему у нас есть отдельная структура под названием i2c_device_id, когда у нас уже есть i2c_client?

Ниже приводится определение i2c_device_id: 

struct i2c_device_id {
    char name[I2C_NAME_SIZE];
    kernel_ulong_t driver_data; /* Data private to the driver */
};

У нас уже есть char name[I2C_NAME_SIZE]; в i2c_client. Мы могли бы также хранить driver_data внутри i2c_client. Почему возникла необходимость определить отдельную структуру под названием i2c_device_id. Я чувствую себя лишним. Может кто-нибудь, пожалуйста, помогите мне в том, что я упускаю, поскольку я верю, что делаю.

EDIT

Похоже, это связано с историей. Пожалуйста, поправьте меня, если я ошибаюсь. i2c_device_id существует долгое время. Затем пришли of_device_id и acpi_device_id. Использование любого из них должно быть достаточно, однако, они не являются взаимоисключающими и могут быть смешанными. Это причина того, что используется дерево устройств, и в драйвере также определена таблица i2c_device_id, зонд также получает i2c_device_id соответствующего устройства. Я попробовал это на датчике для проверки.

Однако для меня они должны быть взаимоисключающими. platform_match выглядит так: https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L965

Таким образом, если совпадение на основе дерева устройств выполнено успешно (OF), то, согласно определению, оно возвращается оттуда, не переходя к i2c_device_id сопоставлению таблицы. Следовательно, драйвер должен получить NULL для i2c_device_id. Но это не так. Может кто-нибудь, пожалуйста, помогите узнать, почему я все еще получаю i2c_device_id в тесте драйвера, когда происходит сопоставление дерева устройств (OF).

...