From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>, Pawel Moll <pawel.moll@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-api@vger.kernel.org, broonie@kernel.org,
Stephen Boyd <sboyd@codeaurora.org>,
linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Kumar Gala <galak@codeaurora.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
Date: Fri, 20 Feb 2015 08:27:27 +0000 [thread overview]
Message-ID: <54E6EFEF.2000200@linaro.org> (raw)
In-Reply-To: <20150219181230.GC795@lunn.ch>
Thanks Andrew for your comments,
On 19/02/15 18:12, Andrew Lunn wrote:
>> +
>> +Required properties:
>> +
>> +eeproms: List of phandle and data cell specifier triplet, one triplet
>> + for each data cell the device might be interested in. The
>> + triplet consists of the phandle to the eeprom provider, then
>> + the offset in byte within that storage device, and the length
>
> bytes
>
>> + in byte of the data we care about.
>
> bytes
Yep will fix it in next version.
>
>> +
>> +Optional properties:
>> +
>> +eeprom-names: List of data cell name strings sorted in the same order
>> + as the resets property. Consumers drivers will use
>
> resets? I guess this text was cut/paste from the reset documentation?\
>
I think so. Will fix it.
>> + eeprom-names to differentiate between multiple cells,
>> + and hence being able to know what these cells are for.
>> +
>> +For example:
>> +
>> + device {
>> + eeproms = <&at24 14 42>;
>
> I like to use 42, but is it realistic to have a soc-rev-id which is 42
> bytes long? How about using 42 as the offset and a sensible length of
> say 4?
Ok, will fix it..
>
>> + eeprom-names = "soc-rev-id";
>> +menuconfig EEPROM
>> + bool "EEPROM Support"
>> + depends on OF
>> + help
>> + Support for EEPROM alike devices.
>
> like.
Ok
>
>> +
>> + This framework is designed to provide a generic interface to EEPROM
>
> EPROMs
Ok.
>
>> +
>> +
>> +static ssize_t bin_attr_eeprom_read_write(struct kobject *kobj,
>> + char *buf, loff_t offset,
>> + size_t count, bool read)
>> +{
>> + struct device *dev = container_of(kobj, struct device, kobj);
>> + struct eeprom_device *eeprom = container_of(dev, struct eeprom_device,
>> + edev);
>> + int rc;
>> +
>> + if (offset > eeprom->size)
>> + return 0;
>> +
>> + if (offset + count > eeprom->size)
>> + count = eeprom->size - offset;
>> +
>> + if (read)
>> + rc = regmap_bulk_read(eeprom->regmap, offset,
>> + buf, count/eeprom->stride);
>
> This division will round down, so you could get one less byte than
> what you expected, and the value you actually return. It seems like
> there should be a check here, the count is a multiple of stride and
> return an error if it is not.
Thats a good catch, I will fix this for other such instances too.
>
>> + else
>> + rc = regmap_bulk_write(eeprom->regmap, offset,
>> + buf, count/eeprom->stride);
>> +
>> + if (IS_ERR_VALUE(rc))
>> + return 0;
>> +
>
> I don't think returning 0 here, and above is the best thing to
> do. Return the real error code from regmap, or EINVAL or some other
> error code for going off the end of the eerpom.
Ok, I will fix the return value here for both the cases.
>
>> + return count;
>> +}
>> +
>> +static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
>> + struct bin_attribute *attr,
>> + char *buf, loff_t offset, size_t count)
>> +{
>> + return bin_attr_eeprom_read_write(kobj, buf, offset, count, true);
>> +}
>> +
>> +static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
>> + struct bin_attribute *attr,
>> + char *buf, loff_t offset, size_t count)
>> +{
>> + return bin_attr_eeprom_read_write(kobj, buf, offset, count, false);
>> +}
>>
>
> These two functions seem to be identical. So just have one of them?
One is read and other is write.. there is a true and false flag at the
end of the call to bin_attr_eeprom_read_write().
>
> +
>> +static struct bin_attribute bin_attr_eeprom = {
>> + .attr = {
>> + .name = "eeprom",
>> + .mode = 0660,
>
> Symbolic values like S_IRUGO | S_IWUSR would be better.
Yep, thats correct, I will fix it.
>
> Are you also sure you want group write?
>
S_IWUSR should be enough.
>> + },
>> + .read = bin_attr_eeprom_read,
>> + .write = bin_attr_eeprom_write,
>> +};
>> +
>> +static struct eeprom_cell *__eeprom_cell_get(struct device_node *node,
>> + int index)
>> +{
>> + struct of_phandle_args args;
>> + struct eeprom_cell *cell;
>> + struct eeprom_device *e, *eeprom = NULL;
>> + int ret;
>> +
>> + ret = of_parse_phandle_with_args(node, "eeproms",
>> + "#eeprom-cells", index, &args);
>> + if (ret)
>> + return ERR_PTR(ret);
>> +
>> + if (args.args_count != 2)
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(&eeprom_list_mutex);
>> +
>> + list_for_each_entry(e, &eeprom_list, list) {
>> + if (args.np == e->edev.of_node) {
>> + eeprom = e;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&eeprom_list_mutex);
>
> Shouldn't you increment a reference count to the eeprom here? You are
> going to have trouble if the eeprom is unregistered and there is a
> call still referring to it.
Yes, Stephen Byod also pointed the same, having owner in eeprom_device
should fix this.
I will fix it in next version.
>
>> +
>> + if (!eeprom)
>> + return ERR_PTR(-EPROBE_DEFER);
>> +
>> + cell = kzalloc(sizeof(*cell), GFP_KERNEL);
>> + if (!cell)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + cell->eeprom = eeprom;
>> + cell->offset = args.args[0];
>> + cell->count = args.args[1];
>> +
>> + return cell;
>> +}
>> +
>> +
>> diff --git a/include/linux/eeprom-consumer.h b/include/linux/eeprom-consumer.h
>> new file mode 100644
>> index 0000000..706ae9d
>> --- /dev/null
>> +++ b/include/linux/eeprom-consumer.h
>> @@ -0,0 +1,73 @@
>> +/*
>> + * EEPROM framework consumer.
>> + *
>> + * Copyright (C) 2015 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> + * Copyright (C) 2013 Maxime Ripard <maxime.ripard@free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#ifndef _LINUX_EEPROM_CONSUMER_H
>> +#define _LINUX_EEPROM_CONSUMER_H
>> +
>> +struct eeprom_cell;
>> +
>> +/**
>> + * eeprom_cell_get(): Get eeprom cell of device form a given index.
>
> of a device for a
>
Ok, will be fixed in next version.
>> + *
>> + * @dev: Device that will be interacted with
>> + * @index: Index of the eeprom cell.
>> + *
>> + * The return value will be an ERR_PTR() on error or a valid pointer
>> + * to a struct eeprom_cell. The eeprom_cell will be freed by the
>> + * eeprom_cell_put().
>> + */
>> +struct eeprom_cell *eeprom_cell_get(struct device *dev, int index);
>> +
>> +/**
>> + * eeprom_cell_get(): Get eeprom cell of device form a given name.
>
> same again
Ok, will be fixed in next version.
>
>> + *
>> + * @dev: Device that will be interacted with
>> + * @name: Name of the eeprom cell.
>> + *
>> + * The return value will be an ERR_PTR() on error or a valid pointer
>> + * to a struct eeprom_cell. The eeprom_cell will be freed by the
>> + * eeprom_cell_put().
>> + */
>> +struct eeprom_cell *eeprom_cell_get_byname(struct device *dev,
>> + const char *name);
>> +
>> +/**
>> + * eeprom_cell_put(): Release previously allocated eeprom cell.
>> + *
>> + * @cell: Previously allocated eeprom cell by eeprom_cell_get()
>> + * or eeprom_cell_get_byname().
>> + */
>> +void eeprom_cell_put(struct eeprom_cell *cell);
>> +
>> +/**
>> + * eeprom_cell_read(): Read a given eeprom cell
>> + *
>> + * @cell: eeprom cell to be read.
>> + * @len: pointer to length of cell which will be populated on successful read.
>> + *
>> + * The return value will be an ERR_PTR() on error or a valid pointer
>> + * to a char * bufffer. The buffer should be freed by the consumer with a
>> + * kfree().
>> + */
>> +char *eeprom_cell_read(struct eeprom_cell *cell, ssize_t *len);
>
> Would void * be better than char *? I guess the contents is mostly
> data, not strings.
Yes, thats sounds sensible.
>
> Andrew
>
>> +
>> +/**
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2015-02-20 8:27 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 17:07 [RFC PATCH 0/3] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-02-19 17:08 ` [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework Srinivas Kandagatla
2015-02-19 18:12 ` Andrew Lunn
2015-02-20 8:27 ` Srinivas Kandagatla [this message]
2015-02-20 2:36 ` Stephen Boyd
2015-02-20 8:14 ` Srinivas Kandagatla
2015-02-20 10:24 ` Srinivas Kandagatla
2015-02-20 17:21 ` Rob Herring
2015-02-20 19:25 ` Srinivas Kandagatla
2015-02-20 22:01 ` Rob Herring
2015-02-21 11:31 ` Srinivas Kandagatla
2015-02-22 14:34 ` Maxime Ripard
2015-02-22 14:32 ` Maxime Ripard
2015-02-23 0:57 ` Rob Herring
2015-02-23 23:11 ` Stephen Boyd
2015-02-24 7:08 ` Srinivas Kandagatla
2015-02-24 9:21 ` Maxime Ripard
2015-02-25 1:30 ` Stephen Boyd
2015-02-26 9:16 ` Srinivas Kandagatla
2015-02-26 13:21 ` Maxime Ripard
2015-02-26 14:56 ` Srinivas Kandagatla
2015-02-26 13:18 ` Maxime Ripard
2015-02-23 9:15 ` Sascha Hauer
2015-02-20 17:46 ` Russell King - ARM Linux
2015-02-20 19:00 ` Srinivas Kandagatla
2015-02-23 15:04 ` Mark Brown
2015-02-23 15:38 ` Srinivas Kandagatla
2015-02-19 17:08 ` [RFC PATCH 2/3] eeprom: sunxi: Move the SID driver to the eeprom framework Srinivas Kandagatla
2015-02-20 17:47 ` Russell King - ARM Linux
2015-02-19 17:08 ` [RFC PATCH 3/3] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-02-20 17:48 ` Russell King - ARM Linux
2015-03-05 9:44 ` [PATCH v1 0/6] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-05 9:45 ` [PATCH v1 1/6] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-05 10:23 ` Paul Bolle
2015-03-05 10:35 ` Srinivas Kandagatla
2015-03-07 15:00 ` Mark Brown
2015-03-09 7:13 ` Srinivas Kandagatla
2015-03-05 9:45 ` [PATCH v1 2/6] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-03-05 9:46 ` [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-03-05 20:11 ` Rob Herring
2015-03-05 22:34 ` Srinivas Kandagatla
2015-03-05 9:46 ` [PATCH v1 4/6] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-03-05 10:15 ` Paul Bolle
2015-03-05 18:36 ` Maxime Ripard
2015-03-05 9:46 ` [PATCH v1 5/6] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-05 10:02 ` Paul Bolle
2015-03-05 10:10 ` Srinivas Kandagatla
2015-03-05 9:46 ` [PATCH v1 6/6] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla
2015-03-13 9:49 ` [PATCH v2 0/7] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-23 21:09 ` Mark Brown
2015-03-23 22:05 ` Srinivas Kandagatla
2015-03-24 9:18 ` Srinivas Kandagatla
2015-03-24 17:23 ` Mark Brown
2015-03-24 18:34 ` Srinivas Kandagatla
2015-03-24 19:02 ` Mark Brown
2015-03-24 19:26 ` Srinivas Kandagatla
2015-03-24 20:55 ` Mark Brown
2015-03-13 9:50 ` [PATCH v2 2/7] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 3/7] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 4/7] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 5/7] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 6/7] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-03-13 9:51 ` [PATCH v2 7/7] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla
2015-03-24 22:28 ` [PATCH v3 0/9] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-24 22:29 ` [PATCH v3 1/9] regmap: Introduce regmap_get_max_register Srinivas Kandagatla
2015-03-24 22:36 ` Mark Brown
2015-03-24 23:05 ` Srinivas Kandagatla
2015-03-24 23:23 ` Joe Perches
2015-03-24 22:30 ` [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla
2015-03-24 22:37 ` Mark Brown
2015-03-24 23:07 ` Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-24 22:53 ` Mark Brown
2015-03-26 16:23 ` Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 4/9] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-03-25 7:16 ` Sascha Hauer
2015-03-25 12:29 ` Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 5/9] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-03-25 7:10 ` Sascha Hauer
2015-03-25 16:40 ` Maxime Ripard
2015-03-24 22:30 ` [PATCH v3 6/9] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 7/9] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-24 22:31 ` [PATCH v3 8/9] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-03-25 0:28 ` Bjorn Andersson
2015-03-24 22:31 ` [PATCH v3 9/9] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla
2015-03-30 21:54 ` [PATCH v4 00/10] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-30 21:56 ` [PATCH v4 01/10] regmap: Introduce regmap_get_max_register Srinivas Kandagatla
2015-05-04 12:05 ` Mark Brown
2015-03-30 21:57 ` [PATCH v4 02/10] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla
2015-03-30 21:57 ` [PATCH v4 03/10] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-30 21:57 ` [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-04-07 18:45 ` Stephen Boyd
2015-04-07 20:09 ` Srinivas Kandagatla
2015-04-09 14:45 ` Stephen Boyd
2015-04-10 11:45 ` Maxime Ripard
2015-05-05 11:46 ` Srinivas Kandagatla
2015-05-08 5:23 ` Sascha Hauer
2015-05-06 17:28 ` Mark Brown
2015-03-30 21:57 ` [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-04-06 13:32 ` Matt Porter
2015-04-06 14:11 ` Rob Herring
2015-04-06 15:04 ` Matt Porter
2015-04-07 17:35 ` Srinivas Kandagatla
2015-04-07 17:46 ` Mark Brown
2015-04-07 18:03 ` Srinivas Kandagatla
2015-04-07 19:46 ` Matt Porter
2015-04-08 9:24 ` Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 06/10] eeprom: Add simple eeprom-mmio consumer helper functions Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 07/10] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 08/10] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 09/10] eeprom: sunxi: Move the SID driver to the eeprom framework Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 10/10] eeprom: Add to MAINTAINERS for " Srinivas Kandagatla
2015-05-21 16:42 ` [PATCH v5 00/11] Add simple NVMEM Framework via regmap Srinivas Kandagatla
2015-05-21 16:42 ` [PATCH v5 01/11] regmap: Introduce regmap_get_max_register Srinivas Kandagatla
2015-05-22 11:18 ` Mark Brown
2015-05-21 16:42 ` [PATCH v5 02/11] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla
2015-05-22 11:19 ` Mark Brown
2015-05-21 16:43 ` [PATCH v5 03/11] nvmem: Add a simple NVMEM framework for nvmem providers Srinivas Kandagatla
2015-06-16 22:43 ` Stephen Boyd
2015-06-18 12:46 ` Srinivas Kandagatla
2015-06-24 0:24 ` Stephen Boyd
2015-06-24 10:05 ` Srinivas Kandagatla
2015-05-21 16:43 ` [PATCH v5 04/11] nvmem: Add a simple NVMEM framework for consumers Srinivas Kandagatla
2015-06-16 22:29 ` Stephen Boyd
2015-06-17 8:00 ` Sascha Hauer
2015-06-18 12:56 ` Srinivas Kandagatla
2015-05-21 16:43 ` [PATCH v5 05/11] nvmem: Add nvmem_device based consumer apis Srinivas Kandagatla
2015-06-16 22:49 ` Stephen Boyd
2015-06-18 12:57 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 06/11] nvmem: Add bindings for simple nvmem framework Srinivas Kandagatla
2015-06-16 22:53 ` Stephen Boyd
2015-06-18 13:01 ` Srinivas Kandagatla
2015-06-19 10:36 ` maitysanchayan
2015-06-19 10:59 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 07/11] nvmem: Add simple nvmem-mmio consumer helper functions Srinivas Kandagatla
2015-06-16 22:58 ` Stephen Boyd
2015-06-18 13:08 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 08/11] nvmem: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-06-16 23:00 ` Stephen Boyd
2015-06-18 13:22 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 09/11] nvmem: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-06-16 23:01 ` Stephen Boyd
2015-05-21 16:45 ` [PATCH v5 11/11] nvmem: Add to MAINTAINERS for nvmem framework Srinivas Kandagatla
2015-05-21 16:45 ` [PATCH v5 10/11] nvmem: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-06-16 23:04 ` Stephen Boyd
2015-06-18 13:09 ` Srinivas Kandagatla
2015-05-25 16:51 ` [PATCH v5 00/11] Add simple NVMEM Framework via regmap Pantelis Antoniou
2015-05-26 9:12 ` Srinivas Kandagatla
2015-05-26 17:54 ` Pantelis Antoniou
2015-05-29 1:20 ` Dan Williams
2015-05-29 7:09 ` Srinivas Kandagatla
2015-05-29 21:44 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54E6EFEF.2000200@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).