| Message ID | 1351699009-4217-1-git-send-email-panto@antoniou-consulting.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 10/31/2012 08:56 AM, Pantelis Antoniou wrote: > Various platforms need access to the EEPROM in other > places besides their platform registration callbacks. > Export the memory accessor to the i2c_client i2c_clients are *not* intrinsically memory, so adding this to the generic i2c_client structure doesn't really make sense. What would the semantics of this interface be with respect to temperature sensors and GPIO expanders? NACK. > and implement > it for the at24 driver. > > And before you ask, no, the platform callback can't be used > for anything that depends on DT. Why can't you just allocate (and populate) a struct at24_platform_data for the device if it isn't supplied by whatever created the device? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi David, On Oct 30, 2012, at 8:46 PM, David Daney wrote: > On 10/31/2012 08:56 AM, Pantelis Antoniou wrote: >> Various platforms need access to the EEPROM in other >> places besides their platform registration callbacks. >> Export the memory accessor to the i2c_client > > i2c_clients are *not* intrinsically memory, so adding this to the generic i2c_client structure doesn't really make sense. What would the semantics of this interface be with respect to temperature sensors and GPIO expanders? > > NACK. > It's only filled in for EEPROM devices. There's no other I2C memory read interface for kernel clients. > >> and implement >> it for the at24 driver. >> >> And before you ask, no, the platform callback can't be used >> for anything that depends on DT. > > Why can't you just allocate (and populate) a struct at24_platform_data for the device if it isn't supplied by whatever created the device? > > > There are no platform_data in the case of device tree only generic-boards. Everything is configured via the DT and there are no callbacks. DT is a purely data driver concept. I'm open to suggestions on how to read an EEPROM from another kernel client, when there's no such thing as platform_data anymore. Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/30/2012 11:51 AM, Pantelis Antoniou wrote: > Hi David, > > On Oct 30, 2012, at 8:46 PM, David Daney wrote: > >> On 10/31/2012 08:56 AM, Pantelis Antoniou wrote: >>> Various platforms need access to the EEPROM in other >>> places besides their platform registration callbacks. >>> Export the memory accessor to the i2c_client >> >> i2c_clients are *not* intrinsically memory, so adding this to the generic i2c_client structure doesn't really make sense. What would the semantics of this interface be with respect to temperature sensors and GPIO expanders? >> >> NACK. >> > > It's only filled in for EEPROM devices. There's no other I2C memory read interface for kernel clients. Basically you are tacking on a registery of memory devices to some random data structure that has nothing to do with memory. Instead ... > >> >>> and implement >>> it for the at24 driver. >>> >>> And before you ask, no, the platform callback can't be used >>> for anything that depends on DT. >> >> Why can't you just allocate (and populate) a struct at24_platform_data for the device if it isn't supplied by whatever created the device? >> >> >> > > There are no platform_data in the case of device tree only generic-boards. Everything is configured via the DT and there are > no callbacks. DT is a purely data driver concept. > > I'm open to suggestions on how to read an EEPROM from another kernel client, when there's no such thing as platform_data anymore. > ... you need some sort of collection memory devices that can be queried by phandle and/or some other handle. Any device that implements the struct memory_accessor interface could add itself to the collection, then code that needs to use the memory_accessor interface would look up the proper target for the operation by phandle or whatever other handle the system is using. Similar to how of_phy_find_device() works. I don't know if it would be possible to create a 'memory_accessor' bus, but that is one idea I had. David Daney > Regards > > -- Pantelis > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c index ab1ad41..4f88ae65 100644 --- a/drivers/misc/eeprom/at24.c +++ b/drivers/misc/eeprom/at24.c @@ -609,6 +609,9 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id) at24->client[0] = client; + /* export accessor */ + client->macc = &at24->macc; + /* use dummy devices for multiple-address chips */ for (i = 1; i < num_addresses; i++) { at24->client[i] = i2c_new_dummy(client->adapter, @@ -619,6 +622,7 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id) err = -EADDRINUSE; goto err_clients; } + at24->client[i]->macc = &at24->macc; } err = sysfs_create_bin_file(&client->dev.kobj, &at24->bin); @@ -637,6 +641,7 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id) I2C_SMBUS_WORD_DATA ? "word" : "byte"); } + /* export data to kernel code */ if (chip.setup) chip.setup(&at24->macc, chip.context); diff --git a/include/linux/i2c.h b/include/linux/i2c.h index 800de22..e20ad4e 100644 --- a/include/linux/i2c.h +++ b/include/linux/i2c.h @@ -33,6 +33,7 @@ #include <linux/of.h> /* for struct device_node */ #include <linux/swab.h> /* for swab16 */ #include <uapi/linux/i2c.h> +#include <linux/memory.h> extern struct bus_type i2c_bus_type; extern struct device_type i2c_adapter_type; @@ -229,9 +230,32 @@ struct i2c_client { struct device dev; /* the device structure */ int irq; /* irq issued by device */ struct list_head detected; + + /* export accessor */ + struct memory_accessor *macc; }; #define to_i2c_client(d) container_of(d, struct i2c_client, dev) +static inline ssize_t i2c_memory_read(struct i2c_client *client, char *buf, off_t offset, + size_t count) +{ + struct memory_accessor *macc = client->macc; + + if (macc == NULL || macc->read == NULL) + return -ENODEV; + return (*client->macc->read)(macc, buf, offset, count); +} + +static inline ssize_t i2c_memory_write(struct i2c_client *client, const char *buf, off_t offset, + size_t count) +{ + struct memory_accessor *macc = client->macc; + + if (macc == NULL || macc->write == NULL) + return -ENODEV; + return (*client->macc->write)(macc, buf, offset, count); +} + extern struct i2c_client *i2c_verify_client(struct device *dev); extern struct i2c_adapter *i2c_verify_adapter(struct device *dev);
Various platforms need access to the EEPROM in other places besides their platform registration callbacks. Export the memory accessor to the i2c_client and implement it for the at24 driver. And before you ask, no, the platform callback can't be used for anything that depends on DT. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/misc/eeprom/at24.c | 5 +++++ include/linux/i2c.h | 24 ++++++++++++++++++++++++ 2 files changed, 29 insertions(+)