Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbbBZO46 (ORCPT ); Thu, 26 Feb 2015 09:56:58 -0500 Received: from mail-we0-f174.google.com ([74.125.82.174]:44736 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753828AbbBZO44 (ORCPT ); Thu, 26 Feb 2015 09:56:56 -0500 Message-ID: <54EF3434.6040003@linaro.org> Date: Thu, 26 Feb 2015 14:56:52 +0000 From: Srinivas Kandagatla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Maxime Ripard CC: Stephen Boyd , Rob Herring , "linux-arm-kernel@lists.infradead.org" , Rob Herring , Pawel Moll , Kumar Gala , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , Arnd Bergmann , Mark Brown , Greg Kroah-Hartman Subject: Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework References: <1424365708-26681-1-git-send-email-srinivas.kandagatla@linaro.org> <54E78A31.9020306@linaro.org> <20150222143211.GX25269@lukather> <54EBB3AC.30000@codeaurora.org> <20150224092155.GO25269@lukather> <20150225013049.GJ24928@codeaurora.org> <54EEE46B.6090905@linaro.org> <20150226132107.GH29241@lukather> In-Reply-To: <20150226132107.GH29241@lukather> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2271 Lines: 75 On 26/02/15 13:21, Maxime Ripard wrote: > On Thu, Feb 26, 2015 at 09:16:27AM +0000, Srinivas Kandagatla wrote: >> I think we are making simple eeprom framework too smart which will >> break in future. >> >> IMHO, Anything on top of eeprom interface that interprets the data should >> not go into the eeprom framework itself, it can either live some parsers/SOC >> specific drivers/interfaces. > > True, but that doesn't mean that this parser support can't be built > within the framework itself. I was more of thinking parsers/interpreters as a layer on top of this framework. Allowing the simplest users direct access to framework. Also just eeprom_read() apis would not cater for all the parsers and I think it would be very difficult to come up with abstracted consumer apis for all the parsers which could be iterator or link-lists parsers or something very different. > >> As Stephen pointed out earlier lets start with something like this, which >> would provide a better abstraction to the discussed use cases like >> serial-number and packed data in eeprom. >> >> 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>, >> }; >> >> tsens-data: tmdata@10 { >> reg = <0x10 40>; >> }; >> >> serial-number: serial@50 { >> compatible = "qcom,serial-msm8960"; >> reg = <0x50 4>, <0x60 4>; >> }; >> >> }; > > And I'm sorry, but I still don't get why the compatibles are needed > here. This is an optional property, only purpose of this would be to serve as parser/soc-specific identifier. > >> and then on the consumer side: >> >> device { >> eeproms = <&serial-number>; >> eeprom-names = "soc-rev-id"; >> }; >> >> driver side: >> >> eeprom_get_cell() >> eeprom_read(); > > Looks good otherwise. thanks --srini > > Maxime > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/