If the slave eeprom has a "firmware-name" in devicetree, then
pre-load the data in the eeprom with this file. Otherwise we
init the eeprom with 0xFF.
Signed-off-by: Björn Ardö <[email protected]>
---
drivers/i2c/i2c-slave-eeprom.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/i2c/i2c-slave-eeprom.c b/drivers/i2c/i2c-slave-eeprom.c
index cb415b10642f..c846c96c25c9 100644
--- a/drivers/i2c/i2c-slave-eeprom.c
+++ b/drivers/i2c/i2c-slave-eeprom.c
@@ -18,6 +18,7 @@
*/
#include <linux/bitfield.h>
+#include <linux/firmware.h>
#include <linux/i2c.h>
#include <linux/init.h>
#include <linux/module.h>
@@ -120,6 +121,26 @@ static ssize_t i2c_slave_eeprom_bin_write(struct file *filp, struct kobject *kob
return count;
}
+static int i2c_slave_init_eeprom_data(struct eeprom_data *eeprom, struct i2c_client *client,
+ unsigned int size)
+{
+ const struct firmware *fw;
+ const char *eeprom_data;
+ int error = device_property_read_string(&client->dev, "firmware-name", &eeprom_data);
+
+ if (!error) {
+ int ret = request_firmware_into_buf(&fw, eeprom_data, &client->dev,
+ eeprom->buffer, size);
+ if (ret)
+ return ret;
+ release_firmware(fw);
+ } else {
+ /* An empty eeprom typically has all bits set to 1 */
+ memset(eeprom->buffer, 0xFF, size);
+ }
+ return 0;
+}
+
static int i2c_slave_eeprom_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct eeprom_data *eeprom;
@@ -138,6 +159,10 @@ static int i2c_slave_eeprom_probe(struct i2c_client *client, const struct i2c_de
spin_lock_init(&eeprom->buffer_lock);
i2c_set_clientdata(client, eeprom);
+ ret = i2c_slave_init_eeprom_data(eeprom, client, size);
+ if (ret)
+ return ret;
+
sysfs_bin_attr_init(&eeprom->bin);
eeprom->bin.attr.name = "slave-eeprom";
eeprom->bin.attr.mode = S_IRUSR | S_IWUSR;
--
2.11.0
On Fri, Apr 24, 2020 at 11:04:43AM +0200, Björn Ardö wrote:
> If the slave eeprom has a "firmware-name" in devicetree, then
> pre-load the data in the eeprom with this file. Otherwise we
> init the eeprom with 0xFF.
>
> Signed-off-by: Björn Ardö <[email protected]>
I like it a lot, thanks! Maybe we could add a SoB from Patrick for his
0xff-suggestion (but keeping you as the patch author).
Is this okay for everyone?
> ---
> drivers/i2c/i2c-slave-eeprom.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/i2c/i2c-slave-eeprom.c b/drivers/i2c/i2c-slave-eeprom.c
> index cb415b10642f..c846c96c25c9 100644
> --- a/drivers/i2c/i2c-slave-eeprom.c
> +++ b/drivers/i2c/i2c-slave-eeprom.c
> @@ -18,6 +18,7 @@
> */
>
> #include <linux/bitfield.h>
> +#include <linux/firmware.h>
> #include <linux/i2c.h>
> #include <linux/init.h>
> #include <linux/module.h>
> @@ -120,6 +121,26 @@ static ssize_t i2c_slave_eeprom_bin_write(struct file *filp, struct kobject *kob
> return count;
> }
>
> +static int i2c_slave_init_eeprom_data(struct eeprom_data *eeprom, struct i2c_client *client,
> + unsigned int size)
> +{
> + const struct firmware *fw;
> + const char *eeprom_data;
> + int error = device_property_read_string(&client->dev, "firmware-name", &eeprom_data);
> +
> + if (!error) {
> + int ret = request_firmware_into_buf(&fw, eeprom_data, &client->dev,
> + eeprom->buffer, size);
> + if (ret)
> + return ret;
> + release_firmware(fw);
> + } else {
> + /* An empty eeprom typically has all bits set to 1 */
> + memset(eeprom->buffer, 0xFF, size);
> + }
> + return 0;
> +}
> +
> static int i2c_slave_eeprom_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> struct eeprom_data *eeprom;
> @@ -138,6 +159,10 @@ static int i2c_slave_eeprom_probe(struct i2c_client *client, const struct i2c_de
> spin_lock_init(&eeprom->buffer_lock);
> i2c_set_clientdata(client, eeprom);
>
> + ret = i2c_slave_init_eeprom_data(eeprom, client, size);
> + if (ret)
> + return ret;
> +
> sysfs_bin_attr_init(&eeprom->bin);
> eeprom->bin.attr.name = "slave-eeprom";
> eeprom->bin.attr.mode = S_IRUSR | S_IWUSR;
> --
> 2.11.0
>
On 4/24/20 12:03 PM, Wolfram Sang wrote:
> On Fri, Apr 24, 2020 at 11:04:43AM +0200, Björn Ardö wrote:
>> If the slave eeprom has a "firmware-name" in devicetree, then
>> pre-load the data in the eeprom with this file. Otherwise we
>> init the eeprom with 0xFF.
>>
>> Signed-off-by: Björn Ardö <[email protected]>
> I like it a lot, thanks! Maybe we could add a SoB from Patrick for his
> 0xff-suggestion (but keeping you as the patch author).
>
> Is this okay for everyone?
OK for me!
On second look, two questions:
> + if (!error) {
> + int ret = request_firmware_into_buf(&fw, eeprom_data, &client->dev,
> + eeprom->buffer, size);
> + if (ret)
> + return ret;
Aren't we leaking 'fw' here?
Also, do we need 'error' and 'ret'? Can't we reuse one of them?
> + release_firmware(fw);
On 4/24/20 1:13 PM, Wolfram Sang wrote:
> On second look, two questions:
>
>> + if (!error) {
>> + int ret = request_firmware_into_buf(&fw, eeprom_data, &client->dev,
>> + eeprom->buffer, size);
>> + if (ret)
>> + return ret;
> Aren't we leaking 'fw' here?
As I can see in drivers/base/firmware_loader/main.c in function
_request_firmware, then the fw will be released internally if it returns
an error value.
> Also, do we need 'error' and 'ret'? Can't we reuse one of them?
Yes, I can fix that.
/BA
> As I can see in drivers/base/firmware_loader/main.c in function
> _request_firmware, then the fw will be released internally if it returns an
> error value.
Ouch, of course!
> > Also, do we need 'error' and 'ret'? Can't we reuse one of them?
>
> Yes, I can fix that.
Great, thanks!
You got a new patch (ignor the first one, I forgot to update the version
number).
On 4/24/20 1:27 PM, Wolfram Sang wrote:
>> As I can see in drivers/base/firmware_loader/main.c in function
>> _request_firmware, then the fw will be released internally if it returns an
>> error value.
> Ouch, of course!
>
>>> Also, do we need 'error' and 'ret'? Can't we reuse one of them?
>> Yes, I can fix that.
> Great, thanks!
>
On Fri, Apr 24, 2020 at 12:06:44PM +0200, Bjorn Ardo wrote:
>
> On 4/24/20 12:03 PM, Wolfram Sang wrote:
> > On Fri, Apr 24, 2020 at 11:04:43AM +0200, Bj?rn Ard? wrote:
> >> If the slave eeprom has a "firmware-name" in devicetree, then
> >> pre-load the data in the eeprom with this file. Otherwise we
> >> init the eeprom with 0xFF.
> >>
> >> Signed-off-by: Bj?rn Ard? <[email protected]>
> > I like it a lot, thanks! Maybe we could add a SoB from Patrick for his
> > 0xff-suggestion (but keeping you as the patch author).
> >
> > Is this okay for everyone?
>
>
> OK for me!
>
Fine by me, also.
--
Patrick Williams