From: Maxime Ripard <maxime.ripard@free-electrons.com> To: Stephen Boyd <sboyd@codeaurora.org> Cc: Rob Herring <robherring2@gmail.com>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>, Kumar Gala <galak@codeaurora.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Mark Brown <broonie@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Subject: Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework Date: Tue, 24 Feb 2015 10:21:55 +0100 [thread overview] Message-ID: <20150224092155.GO25269@lukather> (raw) In-Reply-To: <54EBB3AC.30000@codeaurora.org> [-- Attachment #1: Type: text/plain, Size: 4924 bytes --] On Mon, Feb 23, 2015 at 03:11:40PM -0800, Stephen Boyd wrote: > >>> I would do something more simple that is just a list of keys and > >>> their location like this: > >>> > >>> device-serial-number = <start size>; > >>> key1 = <start size>; > >>> key2 = <start size>; > >> I'm sorry, but what's the difference? > > It can describe the layout completely whether the fields are tied to a > > h/w device or not. > > > > What I would like to see here is the entire layout described covering > > both types of fields. > > > > I was thinking the DT might be like this on the provider side: > > qfprom@1000000 { > reg = <0x1000000 0x1000>; > ranges = <0 0x1000000 0x1000>; > compatible = "qcom,qfprom-msm8960" > > pvs-data: pvs-data@40 { > compatible = "qcom,pvs-a"; > reg = <0x40 0x20>, > #eeprom-cells = <0>; > }; > > tsens-data: tmdata@10 { > compatible = "qcom,tsens-data-msm8960"; > reg = <0x10 4>, <0x16 4>; > #eeprom-cells = <0>; > > }; > > serial-number: serial@50 { > compatible = "qcom,serial-msm8960"; > reg = <0x50 4>, <0x60 4>; > #eeprom-cells = <0>; > > }; > }; I'm not sure the compatible is really needed. A label of some sort, just like the MTD partitions do would do just fine, and wouldn't have the implicit expectation that a driver will be probed from that node. > and then on the consumer side: > > device { > eeproms = <&serial-number>; > eeprom-names = "soc-rev-id"; > }; > > > This would solve a problem where the consumer device is some standard > off-the-shelf IP block that needs to get some SoC specific calibration > data from the eeprom. I may want to interpret the bits differently > depending on which eeprom is connected to my SoC. Sometimes that data > format may be the same across many variations of the SoC (e.g. the > qcom,pvs-a node) or it may be completely different for a given SoC (e.g. > qcom,serial-msm8960 node). I imagine for other SoCs out there it could > be different depending on which eeprom the board manufacturer decides to > wire onto their board and how they choose to program the data. Oh, so you'd like to infer the data format it's stored in from the compatible? AFAICT, this format will be highly depending on the board itself, rather than on the SoC, do you think it will scale enough? > So this is where I think the eeprom-cells and offset + length starts to > fall apart. It forces us to make up a bunch of different compatible > strings for our consumer device just so that we can parse the eeprom > that we decided to use for some SoC/board specific data. Instead I'd > like to see some framework that expresses exactly which eeprom is on my > board and how to interpret the bits in a way that doesn't require me to > keep refining the compatible string for my generic IP block. Hmmmm, apparently you don't :) > I worry that if we put all those details in DT we'll end up having to > describe individual bits like serial-number-bit-2, serial-number-bit-3, > etc. because sometimes these pieces of data are scattered all around the > eeprom and aren't contiguous or aligned on a byte boundary. It may be > easier to just have a way to express that this is an eeprom with this > specific layout and my device has data stored in there. Then the driver > can be told what layout it is (via compatible or some other string based > means if we're not using DT?) and match that up with some driver data if > it needs to know how to understand the bits it can read with the > eeprom_read() API. I'm half convinced that the layout information will actually work for more complex cases, like the linked list Rob described. If such a structure is ever to be found, it would feel wrong to have that in the EEPROM driver, but it would feel just as wrong to put that in the client driver, that would have to handle the parsing of raw data coming flashed by one single crazy board vendor. Maybe we can have each cell carry a property that defines the format it's stored in, and match that to some parsers plugins, starting with the generic and trivial cases but still allowing for custom parsers to be defined? Something like eeprom@42 { compatible = "atmel,at24something"; reg = <0x42>; serial@0 { label = "board serial"; reg = <0x0 0x10>; format = "packed"; }; opps@10 { label = "board serial"; reg = <0x10 0x10>, <0x40 0x10>, <0x80 0x10>; format = "random-vendor,opp-linked-list"; }; }; That would make eeprom_read always return the same format of data to the client drivers, without cripling the generic EEPROM drivers either. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@free-electrons.com (Maxime Ripard) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework Date: Tue, 24 Feb 2015 10:21:55 +0100 [thread overview] Message-ID: <20150224092155.GO25269@lukather> (raw) In-Reply-To: <54EBB3AC.30000@codeaurora.org> On Mon, Feb 23, 2015 at 03:11:40PM -0800, Stephen Boyd wrote: > >>> I would do something more simple that is just a list of keys and > >>> their location like this: > >>> > >>> device-serial-number = <start size>; > >>> key1 = <start size>; > >>> key2 = <start size>; > >> I'm sorry, but what's the difference? > > It can describe the layout completely whether the fields are tied to a > > h/w device or not. > > > > What I would like to see here is the entire layout described covering > > both types of fields. > > > > I was thinking the DT might be like this on the provider side: > > qfprom at 1000000 { > reg = <0x1000000 0x1000>; > ranges = <0 0x1000000 0x1000>; > compatible = "qcom,qfprom-msm8960" > > pvs-data: pvs-data at 40 { > compatible = "qcom,pvs-a"; > reg = <0x40 0x20>, > #eeprom-cells = <0>; > }; > > tsens-data: tmdata at 10 { > compatible = "qcom,tsens-data-msm8960"; > reg = <0x10 4>, <0x16 4>; > #eeprom-cells = <0>; > > }; > > serial-number: serial at 50 { > compatible = "qcom,serial-msm8960"; > reg = <0x50 4>, <0x60 4>; > #eeprom-cells = <0>; > > }; > }; I'm not sure the compatible is really needed. A label of some sort, just like the MTD partitions do would do just fine, and wouldn't have the implicit expectation that a driver will be probed from that node. > and then on the consumer side: > > device { > eeproms = <&serial-number>; > eeprom-names = "soc-rev-id"; > }; > > > This would solve a problem where the consumer device is some standard > off-the-shelf IP block that needs to get some SoC specific calibration > data from the eeprom. I may want to interpret the bits differently > depending on which eeprom is connected to my SoC. Sometimes that data > format may be the same across many variations of the SoC (e.g. the > qcom,pvs-a node) or it may be completely different for a given SoC (e.g. > qcom,serial-msm8960 node). I imagine for other SoCs out there it could > be different depending on which eeprom the board manufacturer decides to > wire onto their board and how they choose to program the data. Oh, so you'd like to infer the data format it's stored in from the compatible? AFAICT, this format will be highly depending on the board itself, rather than on the SoC, do you think it will scale enough? > So this is where I think the eeprom-cells and offset + length starts to > fall apart. It forces us to make up a bunch of different compatible > strings for our consumer device just so that we can parse the eeprom > that we decided to use for some SoC/board specific data. Instead I'd > like to see some framework that expresses exactly which eeprom is on my > board and how to interpret the bits in a way that doesn't require me to > keep refining the compatible string for my generic IP block. Hmmmm, apparently you don't :) > I worry that if we put all those details in DT we'll end up having to > describe individual bits like serial-number-bit-2, serial-number-bit-3, > etc. because sometimes these pieces of data are scattered all around the > eeprom and aren't contiguous or aligned on a byte boundary. It may be > easier to just have a way to express that this is an eeprom with this > specific layout and my device has data stored in there. Then the driver > can be told what layout it is (via compatible or some other string based > means if we're not using DT?) and match that up with some driver data if > it needs to know how to understand the bits it can read with the > eeprom_read() API. I'm half convinced that the layout information will actually work for more complex cases, like the linked list Rob described. If such a structure is ever to be found, it would feel wrong to have that in the EEPROM driver, but it would feel just as wrong to put that in the client driver, that would have to handle the parsing of raw data coming flashed by one single crazy board vendor. Maybe we can have each cell carry a property that defines the format it's stored in, and match that to some parsers plugins, starting with the generic and trivial cases but still allowing for custom parsers to be defined? Something like eeprom at 42 { compatible = "atmel,at24something"; reg = <0x42>; serial at 0 { label = "board serial"; reg = <0x0 0x10>; format = "packed"; }; opps at 10 { label = "board serial"; reg = <0x10 0x10>, <0x40 0x10>, <0x80 0x10>; format = "random-vendor,opp-linked-list"; }; }; That would make eeprom_read always return the same format of data to the client drivers, without cripling the generic EEPROM drivers either. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150224/7139a89c/attachment-0001.sig>
next prev parent reply other threads:[~2015-02-24 9:25 UTC|newest] Thread overview: 385+ 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:07 ` Srinivas Kandagatla 2015-02-19 17:08 ` [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework Srinivas Kandagatla 2015-02-19 17:08 ` Srinivas Kandagatla 2015-02-19 18:12 ` Andrew Lunn 2015-02-19 18:12 ` Andrew Lunn 2015-02-19 18:12 ` Andrew Lunn 2015-02-20 8:27 ` Srinivas Kandagatla 2015-02-20 8:27 ` Srinivas Kandagatla 2015-02-20 8:27 ` Srinivas Kandagatla 2015-02-20 2:36 ` Stephen Boyd 2015-02-20 2:36 ` Stephen Boyd 2015-02-20 2:36 ` Stephen Boyd 2015-02-20 8:14 ` Srinivas Kandagatla 2015-02-20 8:14 ` Srinivas Kandagatla 2015-02-20 10:24 ` Srinivas Kandagatla 2015-02-20 10:24 ` Srinivas Kandagatla 2015-02-20 10:24 ` Srinivas Kandagatla 2015-02-20 17:21 ` Rob Herring 2015-02-20 17:21 ` Rob Herring 2015-02-20 17:21 ` Rob Herring 2015-02-20 19:25 ` Srinivas Kandagatla 2015-02-20 19:25 ` Srinivas Kandagatla 2015-02-20 19:25 ` Srinivas Kandagatla 2015-02-20 22:01 ` Rob Herring 2015-02-20 22:01 ` Rob Herring 2015-02-20 22:01 ` Rob Herring 2015-02-21 11:31 ` Srinivas Kandagatla 2015-02-21 11:31 ` Srinivas Kandagatla 2015-02-21 11:31 ` Srinivas Kandagatla 2015-02-22 14:34 ` Maxime Ripard 2015-02-22 14:34 ` Maxime Ripard 2015-02-22 14:34 ` Maxime Ripard 2015-02-22 14:32 ` Maxime Ripard 2015-02-22 14:32 ` Maxime Ripard 2015-02-22 14:32 ` Maxime Ripard 2015-02-23 0:57 ` Rob Herring 2015-02-23 0:57 ` Rob Herring 2015-02-23 0:57 ` Rob Herring 2015-02-23 23:11 ` Stephen Boyd 2015-02-23 23:11 ` Stephen Boyd 2015-02-23 23:11 ` Stephen Boyd 2015-02-24 7:08 ` Srinivas Kandagatla 2015-02-24 7:08 ` Srinivas Kandagatla 2015-02-24 7:08 ` Srinivas Kandagatla 2015-02-24 9:21 ` Maxime Ripard [this message] 2015-02-24 9:21 ` Maxime Ripard 2015-02-24 9:21 ` Maxime Ripard 2015-02-25 1:30 ` Stephen Boyd 2015-02-25 1:30 ` Stephen Boyd 2015-02-25 1:30 ` Stephen Boyd 2015-02-26 9:16 ` Srinivas Kandagatla 2015-02-26 9:16 ` Srinivas Kandagatla 2015-02-26 9:16 ` Srinivas Kandagatla 2015-02-26 13:21 ` Maxime Ripard 2015-02-26 13:21 ` Maxime Ripard 2015-02-26 13:21 ` Maxime Ripard 2015-02-26 14:56 ` Srinivas Kandagatla 2015-02-26 14:56 ` Srinivas Kandagatla 2015-02-26 14:56 ` Srinivas Kandagatla 2015-02-26 13:18 ` Maxime Ripard 2015-02-26 13:18 ` Maxime Ripard 2015-02-26 13:18 ` Maxime Ripard 2015-02-23 9:15 ` Sascha Hauer 2015-02-23 9:15 ` Sascha Hauer 2015-02-23 9:15 ` Sascha Hauer 2015-02-20 17:46 ` Russell King - ARM Linux 2015-02-20 17:46 ` Russell King - ARM Linux 2015-02-20 17:46 ` Russell King - ARM Linux 2015-02-20 19:00 ` Srinivas Kandagatla 2015-02-20 19:00 ` Srinivas Kandagatla 2015-02-23 15:04 ` Mark Brown 2015-02-23 15:04 ` Mark Brown 2015-02-23 15:04 ` Mark Brown 2015-02-23 15:38 ` Srinivas Kandagatla 2015-02-23 15:38 ` Srinivas Kandagatla 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-19 17:08 ` Srinivas Kandagatla 2015-02-20 17:47 ` Russell King - ARM Linux 2015-02-20 17:47 ` Russell King - ARM Linux 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-19 17:08 ` Srinivas Kandagatla 2015-02-20 17:48 ` Russell King - ARM Linux 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:44 ` 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 9:45 ` Srinivas Kandagatla 2015-03-05 10:23 ` Paul Bolle 2015-03-05 10:23 ` Paul Bolle 2015-03-05 10:35 ` Srinivas Kandagatla 2015-03-05 10:35 ` Srinivas Kandagatla 2015-03-05 10:35 ` Srinivas Kandagatla 2015-03-07 15:00 ` Mark Brown 2015-03-07 15:00 ` Mark Brown 2015-03-07 15:00 ` Mark Brown 2015-03-09 7:13 ` Srinivas Kandagatla 2015-03-09 7:13 ` Srinivas Kandagatla 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:45 ` Srinivas Kandagatla 2015-03-05 9:46 ` [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla 2015-03-05 9:46 ` Srinivas Kandagatla 2015-03-05 20:11 ` Rob Herring 2015-03-05 20:11 ` Rob Herring 2015-03-05 20:11 ` Rob Herring 2015-03-05 22:34 ` Srinivas Kandagatla 2015-03-05 22:34 ` Srinivas Kandagatla 2015-03-05 22:34 ` Srinivas Kandagatla 2015-03-08 22:19 ` Rob Herring 2015-03-05 9:46 ` [PATCH v1 4/6] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla 2015-03-05 9:46 ` Srinivas Kandagatla 2015-03-05 10:15 ` Paul Bolle 2015-03-05 10:15 ` Paul Bolle 2015-03-05 10:15 ` Paul Bolle 2015-03-05 18:36 ` Maxime Ripard 2015-03-05 18:36 ` Maxime Ripard 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 9:46 ` Srinivas Kandagatla 2015-03-05 10:02 ` Paul Bolle 2015-03-05 10:02 ` Paul Bolle 2015-03-05 10:02 ` Paul Bolle 2015-03-05 10:10 ` Srinivas Kandagatla 2015-03-05 10:10 ` Srinivas Kandagatla 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-05 9:46 ` Srinivas Kandagatla 2015-03-13 9:49 ` [PATCH v2 0/7] Add simple EEPROM Framework via regmap Srinivas Kandagatla 2015-03-13 9:49 ` Srinivas Kandagatla 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 ` 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 ` 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 ` Srinivas Kandagatla [not found] ` <1426240157-2383-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-03-13 9:50 ` [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla 2015-03-13 9:50 ` Srinivas Kandagatla 2015-03-13 9:50 ` Srinivas Kandagatla [not found] ` <1426240214-2434-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-03-23 21:09 ` Mark Brown 2015-03-23 21:09 ` Mark Brown 2015-03-23 21:09 ` Mark Brown [not found] ` <20150323210918.GS14954-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-03-23 22:05 ` Srinivas Kandagatla 2015-03-23 22:05 ` Srinivas Kandagatla 2015-03-23 22:05 ` Srinivas Kandagatla [not found] ` <55108E2B.7050305-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-03-24 9:18 ` Srinivas Kandagatla 2015-03-24 9:18 ` Srinivas Kandagatla 2015-03-24 9:18 ` Srinivas Kandagatla 2015-03-24 17:23 ` Mark Brown 2015-03-24 17:23 ` Mark Brown 2015-03-24 18:34 ` Srinivas Kandagatla 2015-03-24 18:34 ` Srinivas Kandagatla 2015-03-24 19:02 ` Mark Brown 2015-03-24 19:02 ` Mark Brown 2015-03-24 19:26 ` Srinivas Kandagatla 2015-03-24 19:26 ` Srinivas Kandagatla 2015-03-24 20:55 ` Mark Brown 2015-03-24 20:55 ` Mark Brown 2015-03-13 9:50 ` [PATCH v2 5/7] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla 2015-03-13 9:50 ` Srinivas Kandagatla 2015-03-13 9:50 ` Srinivas Kandagatla 2015-03-13 9:50 ` [PATCH v2 6/7] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla 2015-03-13 9:50 ` Srinivas Kandagatla 2015-03-13 9:51 ` [PATCH v2 7/7] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla 2015-03-13 9:51 ` Srinivas Kandagatla 2015-03-24 22:28 ` [PATCH v3 0/9] Add simple EEPROM Framework via regmap Srinivas Kandagatla 2015-03-24 22:28 ` Srinivas Kandagatla 2015-03-24 22:29 ` [PATCH v3 1/9] regmap: Introduce regmap_get_max_register Srinivas Kandagatla 2015-03-24 22:29 ` Srinivas Kandagatla 2015-03-24 22:36 ` Mark Brown 2015-03-24 22:36 ` Mark Brown 2015-03-24 23:05 ` Srinivas Kandagatla 2015-03-24 23:05 ` Srinivas Kandagatla 2015-03-24 23:23 ` Joe Perches 2015-03-24 23:23 ` Joe Perches [not found] ` <1427236116-18531-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-03-24 22:30 ` [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla 2015-03-24 22:30 ` Srinivas Kandagatla 2015-03-24 22:30 ` Srinivas Kandagatla 2015-03-24 22:37 ` Mark Brown 2015-03-24 22:37 ` Mark Brown [not found] ` <20150324223745.GC28997-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-03-24 23:07 ` Srinivas Kandagatla 2015-03-24 23:07 ` Srinivas Kandagatla 2015-03-24 23:07 ` Srinivas Kandagatla 2015-03-24 22:30 ` [PATCH v3 7/9] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla 2015-03-24 22:30 ` Srinivas Kandagatla 2015-03-24 22:30 ` 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:30 ` Srinivas Kandagatla 2015-03-24 22:53 ` Mark Brown 2015-03-24 22:53 ` Mark Brown [not found] ` <20150324225317.GD28997-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-03-26 16:23 ` Srinivas Kandagatla 2015-03-26 16:23 ` Srinivas Kandagatla 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-24 22:30 ` Srinivas Kandagatla [not found] ` <1427236219-18709-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-03-25 7:16 ` Sascha Hauer 2015-03-25 7:16 ` Sascha Hauer 2015-03-25 7:16 ` Sascha Hauer 2015-03-25 12:29 ` Srinivas Kandagatla 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-24 22:30 ` Srinivas Kandagatla 2015-03-25 7:10 ` Sascha Hauer 2015-03-25 7:10 ` Sascha Hauer 2015-03-25 7:10 ` Sascha Hauer 2015-03-25 16:40 ` Maxime Ripard 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 ` Srinivas Kandagatla 2015-03-24 22:31 ` [PATCH v3 8/9] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla 2015-03-24 22:31 ` Srinivas Kandagatla 2015-03-25 0:28 ` Bjorn Andersson 2015-03-25 0:28 ` Bjorn Andersson 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-24 22:31 ` Srinivas Kandagatla 2015-03-30 21:54 ` [PATCH v4 00/10] Add simple EEPROM Framework via regmap Srinivas Kandagatla 2015-03-30 21:54 ` Srinivas Kandagatla 2015-03-30 21:56 ` [PATCH v4 01/10] regmap: Introduce regmap_get_max_register Srinivas Kandagatla 2015-03-30 21:56 ` Srinivas Kandagatla 2015-05-04 12:05 ` Mark Brown 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 ` 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 ` Srinivas Kandagatla [not found] ` <1427752492-17039-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-03-30 21:57 ` [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla 2015-03-30 21:57 ` Srinivas Kandagatla 2015-03-30 21:57 ` Srinivas Kandagatla 2015-04-07 18:45 ` Stephen Boyd 2015-04-07 18:45 ` Stephen Boyd 2015-04-07 20:09 ` Srinivas Kandagatla 2015-04-07 20:09 ` Srinivas Kandagatla 2015-04-09 14:45 ` Stephen Boyd 2015-04-09 14:45 ` Stephen Boyd 2015-04-10 11:45 ` Maxime Ripard 2015-04-10 11:45 ` Maxime Ripard [not found] ` <20150409144522.GB9663-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-05-05 11:46 ` Srinivas Kandagatla 2015-05-05 11:46 ` Srinivas Kandagatla 2015-05-05 11:46 ` Srinivas Kandagatla 2015-05-08 5:23 ` Sascha Hauer 2015-05-08 5:23 ` Sascha Hauer 2015-05-06 17:28 ` Mark Brown 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-03-30 21:57 ` Srinivas Kandagatla 2015-03-30 21:57 ` Srinivas Kandagatla [not found] ` <1427752679-17261-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-04-06 13:32 ` Matt Porter 2015-04-06 13:32 ` Matt Porter 2015-04-06 13:32 ` Matt Porter 2015-04-06 14:11 ` Rob Herring 2015-04-06 14:11 ` Rob Herring 2015-04-06 14:11 ` Rob Herring [not found] ` <CAL_Jsq++9pyJMLXssgyz2WRU4e7ikT_6FwzWMo1fKS82FJvEyg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-04-06 15:04 ` Matt Porter 2015-04-06 15:04 ` Matt Porter 2015-04-06 15:04 ` Matt Porter 2015-04-07 17:35 ` Srinivas Kandagatla 2015-04-07 17:35 ` Srinivas Kandagatla 2015-04-07 17:35 ` Srinivas Kandagatla 2015-04-07 17:46 ` Mark Brown 2015-04-07 17:46 ` Mark Brown 2015-04-07 17:46 ` Mark Brown 2015-04-07 18:03 ` Srinivas Kandagatla 2015-04-07 18:03 ` Srinivas Kandagatla 2015-04-07 18:03 ` Srinivas Kandagatla 2015-04-07 19:46 ` Matt Porter 2015-04-07 19:46 ` Matt Porter 2015-04-07 19:46 ` Matt Porter 2015-04-08 9:24 ` Srinivas Kandagatla 2015-04-08 9:24 ` Srinivas Kandagatla 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 ` Srinivas Kandagatla 2015-03-30 21:58 ` Srinivas Kandagatla 2015-03-30 21:58 ` [PATCH v4 07/10] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla 2015-03-30 21:58 ` Srinivas Kandagatla 2015-03-30 21:58 ` [PATCH v4 08/10] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla 2015-03-30 21:58 ` 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 ` Srinivas Kandagatla 2015-03-30 21:58 ` [PATCH v4 10/10] eeprom: Add to MAINTAINERS for " Srinivas Kandagatla 2015-03-30 21:58 ` Srinivas Kandagatla 2015-05-21 16:42 ` [PATCH v5 00/11] Add simple NVMEM Framework via regmap Srinivas Kandagatla 2015-05-21 16:42 ` Srinivas Kandagatla 2015-05-21 16:42 ` [PATCH v5 01/11] regmap: Introduce regmap_get_max_register Srinivas Kandagatla 2015-05-21 16:42 ` Srinivas Kandagatla 2015-05-22 11:18 ` Mark Brown 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-21 16:42 ` Srinivas Kandagatla 2015-05-22 11:19 ` Mark Brown 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-05-21 16:43 ` Srinivas Kandagatla [not found] ` <1432226583-8775-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-06-16 22:43 ` Stephen Boyd 2015-06-16 22:43 ` Stephen Boyd 2015-06-16 22:43 ` Stephen Boyd [not found] ` <5580A678.4080304-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-06-18 12:46 ` Srinivas Kandagatla 2015-06-18 12:46 ` Srinivas Kandagatla 2015-06-18 12:46 ` Srinivas Kandagatla [not found] ` <5582BDAE.5040008-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-06-24 0:24 ` Stephen Boyd 2015-06-24 0:24 ` Stephen Boyd 2015-06-24 0:24 ` Stephen Boyd 2015-06-24 10:05 ` Srinivas Kandagatla 2015-06-24 10:05 ` Srinivas Kandagatla 2015-05-21 16:43 ` [PATCH v5 05/11] nvmem: Add nvmem_device based consumer apis Srinivas Kandagatla 2015-05-21 16:43 ` Srinivas Kandagatla 2015-06-16 22:49 ` Stephen Boyd 2015-06-16 22:49 ` Stephen Boyd [not found] ` <5580A7EA.2090909-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-06-18 12:57 ` Srinivas Kandagatla 2015-06-18 12:57 ` Srinivas Kandagatla 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-05-21 16:44 ` Srinivas Kandagatla 2015-06-16 22:53 ` Stephen Boyd 2015-06-16 22:53 ` Stephen Boyd [not found] ` <5580A900.9070902-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-06-18 13:01 ` Srinivas Kandagatla 2015-06-18 13:01 ` Srinivas Kandagatla 2015-06-18 13:01 ` Srinivas Kandagatla [not found] ` <1432226652-8947-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-06-19 10:36 ` maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w 2015-06-19 10:36 ` maitysanchayan at gmail.com 2015-06-19 10:36 ` maitysanchayan 2015-06-19 10:59 ` Srinivas Kandagatla 2015-06-19 10:59 ` Srinivas Kandagatla 2015-06-19 10:59 ` Srinivas Kandagatla 2015-05-21 16:44 ` [PATCH v5 08/11] nvmem: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla 2015-05-21 16:44 ` Srinivas Kandagatla 2015-06-16 23:00 ` Stephen Boyd 2015-06-16 23:00 ` Stephen Boyd [not found] ` <5580AA9B.7040001-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-06-18 13:22 ` Srinivas Kandagatla 2015-06-18 13:22 ` Srinivas Kandagatla 2015-06-18 13:22 ` Srinivas Kandagatla [not found] ` <1432226535-8640-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-05-21 16:43 ` [PATCH v5 04/11] nvmem: Add a simple NVMEM framework for consumers Srinivas Kandagatla 2015-05-21 16:43 ` Srinivas Kandagatla 2015-05-21 16:43 ` Srinivas Kandagatla 2015-06-16 22:29 ` Stephen Boyd 2015-06-16 22:29 ` Stephen Boyd 2015-06-17 8:00 ` Sascha Hauer 2015-06-17 8:00 ` Sascha Hauer 2015-06-18 12:56 ` Srinivas Kandagatla 2015-06-18 12:56 ` Srinivas Kandagatla 2015-05-21 16:44 ` [PATCH v5 07/11] nvmem: Add simple nvmem-mmio consumer helper functions Srinivas Kandagatla 2015-05-21 16:44 ` Srinivas Kandagatla 2015-05-21 16:44 ` Srinivas Kandagatla [not found] ` <1432226665-8994-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-06-16 22:58 ` Stephen Boyd 2015-06-16 22:58 ` Stephen Boyd 2015-06-16 22:58 ` Stephen Boyd [not found] ` <5580AA05.90709-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-06-18 13:08 ` Srinivas Kandagatla 2015-06-18 13:08 ` Srinivas Kandagatla 2015-06-18 13:08 ` Srinivas Kandagatla 2015-05-21 16:44 ` [PATCH v5 09/11] nvmem: qfprom: Add bindings for qfprom Srinivas Kandagatla 2015-05-21 16:44 ` Srinivas Kandagatla 2015-05-21 16:44 ` Srinivas Kandagatla [not found] ` <1432226685-9081-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-06-16 23:01 ` Stephen Boyd 2015-06-16 23:01 ` Stephen Boyd 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 ` Srinivas Kandagatla 2015-05-21 16:45 ` Srinivas Kandagatla 2015-05-21 16:45 ` [PATCH v5 10/11] nvmem: sunxi: Move the SID driver to the " Srinivas Kandagatla 2015-05-21 16:45 ` Srinivas Kandagatla [not found] ` <1432226733-9243-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-06-16 23:04 ` Stephen Boyd 2015-06-16 23:04 ` Stephen Boyd 2015-06-16 23:04 ` Stephen Boyd 2015-06-18 13:09 ` Srinivas Kandagatla 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-25 16:51 ` Pantelis Antoniou 2015-05-26 9:12 ` Srinivas Kandagatla 2015-05-26 9:12 ` Srinivas Kandagatla 2015-05-26 9:12 ` Srinivas Kandagatla [not found] ` <556438FF.7020105-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2015-05-26 17:54 ` Pantelis Antoniou 2015-05-26 17:54 ` Pantelis Antoniou 2015-05-26 17:54 ` Pantelis Antoniou 2015-05-29 1:20 ` Dan Williams 2015-05-29 1:20 ` Dan Williams 2015-05-29 1:20 ` Dan Williams [not found] ` <CAA9_cmetqnqTQPCd8ya5AJPKQw8ary8CwsE6TUv=f57O=_MH5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-05-29 7:09 ` Srinivas Kandagatla 2015-05-29 7:09 ` Srinivas Kandagatla 2015-05-29 7:09 ` Srinivas Kandagatla 2015-05-29 21:44 ` Dan Williams 2015-05-29 21:44 ` Dan Williams 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=20150224092155.GO25269@lukather \ --to=maxime.ripard@free-electrons.com \ --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=pawel.moll@arm.com \ --cc=robh+dt@kernel.org \ --cc=robherring2@gmail.com \ --cc=sboyd@codeaurora.org \ --cc=srinivas.kandagatla@linaro.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.