为什么i2c_device_id是单独定义的而不是i2c_client的一部分

Question

为什么已经有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的单独结构。我感到多余。有人可以帮助我，我相信我会错过什么。

编辑

似乎它还与历史有关。如果我错了，请纠正我。 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表匹配。因此，驱动程序探针应为i2c_device_id接收NULL。但这种情况并非如此。有人可以帮忙找出为什么在设备树匹配（OF）发生时我仍然在驱动程序探针中得到i2c_device_id的原因。