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 <[email protected]>
---
drivers/misc/eeprom/at24.c | 5 +++++
include/linux/i2c.h | 24 ++++++++++++++++++++++++
2 files changed, 29 insertions(+)
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);
--
1.7.12
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?
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>