Message ID | 20170809101256.31204-1-javierm@redhat.com |
---|---|
State | Rejected |
Headers | show |
On Wed, Aug 09, 2017 at 12:12:56PM +0200, Javier Martinez Canillas wrote: > The driver doesn't have a struct of_device_id table but supported devices > are registered via Device Trees as shown in the following DT binding doc: > > Documentation/devicetree/bindings/i2c/i2c-designware.txt Uhhh, that needs to be fixed to something else! I don't think i2c slave functionality should be described in DT. The slave functionality is pure software, so IMO it doesn't match the "HW description" requirement. > But this works on the assumption that a I2C device registered via OF will > always match a legacy I2C device ID and that the MODALIAS reported will > always be of the form i2c:<device>. > > And this could change in the future so the correct approach is to have an > OF device ID table if the devices are registered via OF. > > Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Thanks for finding the issue, still NAK to this patch. Are you interested in updating the docs?
Hello Wolfram, On 08/14/2017 09:52 PM, Wolfram Sang wrote: > On Wed, Aug 09, 2017 at 12:12:56PM +0200, Javier Martinez Canillas wrote: >> The driver doesn't have a struct of_device_id table but supported devices >> are registered via Device Trees as shown in the following DT binding doc: >> >> Documentation/devicetree/bindings/i2c/i2c-designware.txt > > Uhhh, that needs to be fixed to something else! I don't think i2c slave > functionality should be described in DT. The slave functionality is pure > software, so IMO it doesn't match the "HW description" requirement. > Right, indeed. >> But this works on the assumption that a I2C device registered via OF will >> always match a legacy I2C device ID and that the MODALIAS reported will >> always be of the form i2c:<device>. >> >> And this could change in the future so the correct approach is to have an >> OF device ID table if the devices are registered via OF. >> >> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> > > Thanks for finding the issue, still NAK to this patch. Are you > interested in updating the docs? > What kind of change are you looking for? The example was introduced by commit 04606ccc84e3 ("i2c: designware: introducing I2C_SLAVE definitions") that says: - A example was added to designware-core.txt Documentation that shows how the slave can be setup using DTS So I could change this example to instead use a real EEPROM compatible (e.g: "microchip,24c02") instead of "linux,slave-24c02". Would that be correct? Best regards,
> What kind of change are you looking for? The example was introduced by commit > 04606ccc84e3 ("i2c: designware: introducing I2C_SLAVE definitions") that says: > > - A example was added to designware-core.txt Documentation that shows > how the slave can be setup using DTS My fault, I missed it :( > So I could change this example to instead use a real EEPROM compatible (e.g: > "microchip,24c02") instead of "linux,slave-24c02". Would that be correct? I think this is Luis call how he'd like this to be changed. Given the current discussion, I'd think it must be dropped entirely. Luis?
diff --git a/drivers/i2c/i2c-slave-eeprom.c b/drivers/i2c/i2c-slave-eeprom.c index b2039f94c9d8..20226860cfe7 100644 --- a/drivers/i2c/i2c-slave-eeprom.c +++ b/drivers/i2c/i2c-slave-eeprom.c @@ -17,6 +17,7 @@ #include <linux/i2c.h> #include <linux/init.h> #include <linux/module.h> +#include <linux/of_device.h> #include <linux/of.h> #include <linux/slab.h> #include <linux/spinlock.h> @@ -108,7 +109,12 @@ static int i2c_slave_eeprom_probe(struct i2c_client *client, const struct i2c_de { struct eeprom_data *eeprom; int ret; - unsigned size = id->driver_data; + unsigned size; + + if (client->dev.of_node) + size = (kernel_ulong_t)of_device_get_match_data(&client->dev); + else + size = id->driver_data; eeprom = devm_kzalloc(&client->dev, sizeof(struct eeprom_data) + size, GFP_KERNEL); if (!eeprom) @@ -154,9 +160,16 @@ static const struct i2c_device_id i2c_slave_eeprom_id[] = { }; MODULE_DEVICE_TABLE(i2c, i2c_slave_eeprom_id); +static const struct of_device_id i2c_slave_eeprom_of_match[] = { + { .compatible = "linux,slave-24c02", .data = (void *)(2048 / 8) }, + { } +}; +MODULE_DEVICE_TABLE(of, i2c_slave_eeprom_of_match); + static struct i2c_driver i2c_slave_eeprom_driver = { .driver = { .name = "i2c-slave-eeprom", + .of_match_table = i2c_slave_eeprom_of_match, }, .probe = i2c_slave_eeprom_probe, .remove = i2c_slave_eeprom_remove,
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees as shown in the following DT binding doc: Documentation/devicetree/bindings/i2c/i2c-designware.txt But this works on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. And this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> --- drivers/i2c/i2c-slave-eeprom.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)