Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752160AbbBWA56 (ORCPT ); Sun, 22 Feb 2015 19:57:58 -0500 Received: from mail-we0-f170.google.com ([74.125.82.170]:40523 "EHLO mail-we0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751883AbbBWA54 (ORCPT ); Sun, 22 Feb 2015 19:57:56 -0500 MIME-Version: 1.0 In-Reply-To: <20150222143211.GX25269@lukather> References: <1424365639-26634-1-git-send-email-srinivas.kandagatla@linaro.org> <1424365708-26681-1-git-send-email-srinivas.kandagatla@linaro.org> <54E78A31.9020306@linaro.org> <20150222143211.GX25269@lukather> From: Rob Herring Date: Sun, 22 Feb 2015 18:57:34 -0600 Message-ID: Subject: Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework To: Maxime Ripard Cc: Srinivas Kandagatla , "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" , Stephen Boyd , 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 Content-Length: 2988 Lines: 87 On Sun, Feb 22, 2015 at 8:32 AM, Maxime Ripard wrote: > On Fri, Feb 20, 2015 at 04:01:55PM -0600, Rob Herring wrote: >> [...] >> >> >>> += Data consumers = >> >>> + >> >>> +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 >> >>> + in byte of the data we care about. >> >> >> >> >> >> The problem with this is it assumes you know who the consumer is and >> >> that it is a DT node. For example, how would you describe a serial >> >> number? >> > >> > Correct me if I miss understood. >> > Is serial number any different? >> > Am hoping that the eeprom consumer would be aware of offset and size of >> > serial number in the eeprom >> > >> > Cant the consumer do: >> > >> > eeprom-consumer { >> > eeproms = <&at24 0 4>; >> > eeprom-names = "device-serial-number"; >> >> Yes, but who is "eeprom-consumer"? > > Any device that should lookup values in one of the EEPROM. > >> DT nodes generally describe a h/w block, but it this case, the >> consumer depends on the OS, not the h/w. > > Not really, or at least, not more than any similar binding we > currently have. > > The fact that a MAC-address for the first ethernet chip is stored at a > given offset in a given eeprom has nothing to do with the OS. So MAC address would be a valid use to link to a h/w device, but there are certainly cases that don't correspond to a device. >> I'm not saying you can't describe where things are, but I don't >> think you should imply who is the consumer and doing so is >> unnecessarily complicated. > > If you only take the case of a serial number, indeed. If you take > other usage into account, you can't really do without it. > >> Also, the layout of EEPROM is likely very much platform specific. > > Indeed, which is why it should be in the DT. Agreed. I'm not saying the layout should not be. >> Some could have a more complex structure perhaps with key ids and >> linked list structure. > > Then just request the size of the whole list, and parse it afterwards > in your driver? > >> I would do something more simple that is just a list of keys and their >> location like this: >> >> device-serial-number = ; >> key1 = ; >> key2 = ; > > 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. Rob -- 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/