From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932994AbbCEULv (ORCPT ); Thu, 5 Mar 2015 15:11:51 -0500 Received: from mail-wg0-f48.google.com ([74.125.82.48]:40569 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756744AbbCEULs (ORCPT ); Thu, 5 Mar 2015 15:11:48 -0500 MIME-Version: 1.0 In-Reply-To: <1425548765-13019-1-git-send-email-srinivas.kandagatla@linaro.org> References: <1425548685-12887-1-git-send-email-srinivas.kandagatla@linaro.org> <1425548765-13019-1-git-send-email-srinivas.kandagatla@linaro.org> From: Rob Herring Date: Thu, 5 Mar 2015 14:11:26 -0600 Message-ID: Subject: Re: [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework To: Srinivas Kandagatla Cc: "linux-arm-kernel@lists.infradead.org" , Maxime Ripard , Rob Herring , Pawel Moll , Kumar Gala , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Stephen Boyd , Andrew Lunn , Arnd Bergmann , Mark Brown , Greg Kroah-Hartman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 5, 2015 at 3:46 AM, Srinivas Kandagatla wrote: > This patch adds bindings for simple eeprom framework which allows eeprom > consumers to talk to eeprom providers to get access to eeprom cell data. > > Signed-off-by: Maxime Ripard > [Maxime Ripard: intial version of eeprom framework] > Signed-off-by: Srinivas Kandagatla > --- > .../devicetree/bindings/eeprom/eeprom.txt | 70 ++++++++++++++++++++++ > 1 file changed, 70 insertions(+) > create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt > > diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt > new file mode 100644 > index 0000000..dbfb95c > --- /dev/null > +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt > @@ -0,0 +1,70 @@ > += EEPROM Data Device Tree Bindings = > + > +This binding is intended to represent the location of hardware > +configuration data stored in EEPROMs. > + > +On a significant proportion of boards, the manufacturer has stored > +some data on an EEPROM-like device, for the OS to be able to retrieve > +these information and act upon it. Obviously, the OS has to know > +about where to retrieve these data from, and where they are stored on > +the storage device. > + > +This document is here to document this. > + > += Data providers = > +Contains bindings specific to provider drivers and data cells as children > +to this node. > + > += Data cells = > +These are the child nodes of the provider which contain data cell > +information like offset and size in eeprom provider. > + > +Required properties: > +reg: specifies the offset in byte within that storage device, and the length > + in bytes of the data we care about. > + There could be more then one offset-length pairs in this property. > + > +Optional properties: > +As required by specific data parsers/interpreters. > + > +For example: > + > + /* Provider */ > + qfprom: qfprom@00700000 { > + compatible = "qcom,qfprom"; > + reg = <0x00700000 0x1000>; > + ... > + > + /* Data cells */ > + tsens_calibration: calib@404 { > + reg = <0x404 0x10>; > + }; > + > + serial_number: sn { > + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>; > + > + }; > + ... > + }; > + > += Data consumers = > +Are drivers which consume eeprom data cells. s/drivers/device nodes/ > + > +Required properties: > + > +eeproms: List of phandle and data cell the device might be interested in. > + > +Optional properties: > + > +eeprom-names: List of data cell name strings sorted in the same order > + as the resets property. Consumers drivers will use resets? > + eeprom-names to differentiate between multiple cells, > + and hence being able to know what these cells are for. Is this still needed? The sub-node name defines the name. Or you can use reg-names with-in the sub-node. Rob > + > +For example: > + > + tsens { > + ... > + eeproms = <&tsens_calibration>; > + eeprom-names = "calibration"; > + }; > -- > 1.9.1 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework Date: Thu, 5 Mar 2015 14:11:26 -0600 Message-ID: References: <1425548685-12887-1-git-send-email-srinivas.kandagatla@linaro.org> <1425548765-13019-1-git-send-email-srinivas.kandagatla@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1425548765-13019-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Srinivas Kandagatla Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Maxime Ripard , Rob Herring , Pawel Moll , Kumar Gala , "linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Stephen Boyd , Andrew Lunn , Arnd Bergmann , Mark Brown , Greg Kroah-Hartman List-Id: devicetree@vger.kernel.org On Thu, Mar 5, 2015 at 3:46 AM, Srinivas Kandagatla wrote: > This patch adds bindings for simple eeprom framework which allows eeprom > consumers to talk to eeprom providers to get access to eeprom cell data. > > Signed-off-by: Maxime Ripard > [Maxime Ripard: intial version of eeprom framework] > Signed-off-by: Srinivas Kandagatla > --- > .../devicetree/bindings/eeprom/eeprom.txt | 70 ++++++++++++++++++++++ > 1 file changed, 70 insertions(+) > create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt > > diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt > new file mode 100644 > index 0000000..dbfb95c > --- /dev/null > +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt > @@ -0,0 +1,70 @@ > += EEPROM Data Device Tree Bindings = > + > +This binding is intended to represent the location of hardware > +configuration data stored in EEPROMs. > + > +On a significant proportion of boards, the manufacturer has stored > +some data on an EEPROM-like device, for the OS to be able to retrieve > +these information and act upon it. Obviously, the OS has to know > +about where to retrieve these data from, and where they are stored on > +the storage device. > + > +This document is here to document this. > + > += Data providers = > +Contains bindings specific to provider drivers and data cells as children > +to this node. > + > += Data cells = > +These are the child nodes of the provider which contain data cell > +information like offset and size in eeprom provider. > + > +Required properties: > +reg: specifies the offset in byte within that storage device, and the length > + in bytes of the data we care about. > + There could be more then one offset-length pairs in this property. > + > +Optional properties: > +As required by specific data parsers/interpreters. > + > +For example: > + > + /* Provider */ > + qfprom: qfprom@00700000 { > + compatible = "qcom,qfprom"; > + reg = <0x00700000 0x1000>; > + ... > + > + /* Data cells */ > + tsens_calibration: calib@404 { > + reg = <0x404 0x10>; > + }; > + > + serial_number: sn { > + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>; > + > + }; > + ... > + }; > + > += Data consumers = > +Are drivers which consume eeprom data cells. s/drivers/device nodes/ > + > +Required properties: > + > +eeproms: List of phandle and data cell the device might be interested in. > + > +Optional properties: > + > +eeprom-names: List of data cell name strings sorted in the same order > + as the resets property. Consumers drivers will use resets? > + eeprom-names to differentiate between multiple cells, > + and hence being able to know what these cells are for. Is this still needed? The sub-node name defines the name. Or you can use reg-names with-in the sub-node. Rob > + > +For example: > + > + tsens { > + ... > + eeproms = <&tsens_calibration>; > + eeprom-names = "calibration"; > + }; > -- > 1.9.1 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: robherring2@gmail.com (Rob Herring) Date: Thu, 5 Mar 2015 14:11:26 -0600 Subject: [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework In-Reply-To: <1425548765-13019-1-git-send-email-srinivas.kandagatla@linaro.org> References: <1425548685-12887-1-git-send-email-srinivas.kandagatla@linaro.org> <1425548765-13019-1-git-send-email-srinivas.kandagatla@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Mar 5, 2015 at 3:46 AM, Srinivas Kandagatla wrote: > This patch adds bindings for simple eeprom framework which allows eeprom > consumers to talk to eeprom providers to get access to eeprom cell data. > > Signed-off-by: Maxime Ripard > [Maxime Ripard: intial version of eeprom framework] > Signed-off-by: Srinivas Kandagatla > --- > .../devicetree/bindings/eeprom/eeprom.txt | 70 ++++++++++++++++++++++ > 1 file changed, 70 insertions(+) > create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt > > diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt > new file mode 100644 > index 0000000..dbfb95c > --- /dev/null > +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt > @@ -0,0 +1,70 @@ > += EEPROM Data Device Tree Bindings = > + > +This binding is intended to represent the location of hardware > +configuration data stored in EEPROMs. > + > +On a significant proportion of boards, the manufacturer has stored > +some data on an EEPROM-like device, for the OS to be able to retrieve > +these information and act upon it. Obviously, the OS has to know > +about where to retrieve these data from, and where they are stored on > +the storage device. > + > +This document is here to document this. > + > += Data providers = > +Contains bindings specific to provider drivers and data cells as children > +to this node. > + > += Data cells = > +These are the child nodes of the provider which contain data cell > +information like offset and size in eeprom provider. > + > +Required properties: > +reg: specifies the offset in byte within that storage device, and the length > + in bytes of the data we care about. > + There could be more then one offset-length pairs in this property. > + > +Optional properties: > +As required by specific data parsers/interpreters. > + > +For example: > + > + /* Provider */ > + qfprom: qfprom at 00700000 { > + compatible = "qcom,qfprom"; > + reg = <0x00700000 0x1000>; > + ... > + > + /* Data cells */ > + tsens_calibration: calib at 404 { > + reg = <0x404 0x10>; > + }; > + > + serial_number: sn { > + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>; > + > + }; > + ... > + }; > + > += Data consumers = > +Are drivers which consume eeprom data cells. s/drivers/device nodes/ > + > +Required properties: > + > +eeproms: List of phandle and data cell the device might be interested in. > + > +Optional properties: > + > +eeprom-names: List of data cell name strings sorted in the same order > + as the resets property. Consumers drivers will use resets? > + eeprom-names to differentiate between multiple cells, > + and hence being able to know what these cells are for. Is this still needed? The sub-node name defines the name. Or you can use reg-names with-in the sub-node. Rob > + > +For example: > + > + tsens { > + ... > + eeproms = <&tsens_calibration>; > + eeprom-names = "calibration"; > + }; > -- > 1.9.1 >