From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbcCHXaB (ORCPT ); Tue, 8 Mar 2016 18:30:01 -0500 Received: from mail.kymetacorp.com ([192.81.58.21]:44664 "EHLO mail.kymetacorp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750985AbcCHX3z (ORCPT ); Tue, 8 Mar 2016 18:29:55 -0500 X-Greylist: delayed 320 seconds by postgrey-1.27 at vger.kernel.org; Tue, 08 Mar 2016 18:29:55 EST From: Trent Piepho To: Andrey Smirnov CC: Maxime Ripard , Srinivas Kandagatla , "linux-kernel@vger.kernel.org" , Sascha Hauer Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Thread-Topic: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Thread-Index: AQHRdKfo4hZbpUfeq0yKL82tRTv6x59OMLcAgAFMM4CAATOGgIAABSwAgAAKuoA= Date: Tue, 8 Mar 2016 23:24:33 +0000 Message-ID: <1457479515.25961.162.camel@rtred1test09.kymeta.local> References: <1456851552-15913-1-git-send-email-andrew.smirnov@gmail.com> <1456851552-15913-3-git-send-email-andrew.smirnov@gmail.com> <56D6F188.2090406@linaro.org> <20160307081842.GA8418@lukather> <20160308222821.GL8418@lukather> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.8.5 (3.8.5-31.el7) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.10.42.160] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u28NU7nZ028047 On Tue, 2016-03-08 at 14:46 -0800, Andrey Smirnov wrote: > >> I don't think I understand what you mean, could you give me an example > >> of how I'd use local-mac-address property for that use case? AFAIK, > >> local-mac-address is just an array of bytes embedded into device tree, > > > > Well, yeah, but the nvmem-blob is also just an array of bytes embedded > > into the DT, right? > > One is accessible via "nvmem" API and the other one isn't. > > > > >> how would it get populated with data from OTP memory of SoC? > > > > In the bootloader, or Linux, read the OTP, patch the DT to add that > > node, done. > > No, it's not really "done", because if you read my previous messages, > "read the OTP, patch the DT" is exactly the problem I am trying to > solve. The overall goal is to be able to read a certain "nvmem" cell > and patch DT with that data as MAC address, however in it's current > incarnation "nvmem" doesn't have provisions to make cells that are > just combination of other cells (patch #3) and to embed certain data So I did something that solved this a few years ago for another board and embedded the data into the local-mac-address property. I think maybe the problem isn't here isn't clear. For some boards (mxs), only part of a MAC address is stored in nvmem while the rest of the address is fixed data. Currently embedded in the kernel source, though embedded in the device tree would clearly be better. While splitting the MAC into two locations like this is not, at least in my opinion, the best design, it's burned into the one time programmable memory so there's not much that can be done. The kernel looks for 'mac-address' and then 'local-mac-address', with the former having precedence. So what I did was embed the fixed portion in 'local-mac-address', have the bootloader extract the variable part from nvmem, and then combine the two and place it into 'mac-address' for the kernel to use. My DT binding that described the placement of data from nvmem into the MAC used a permutation list instead of a series of ranges. So a list like [0 0 0 1 2 3] could be used to specify the first three bytes of the mac address do not come from nvmem. This also allows changing byte order concisely. But doesn't scale well to larger regions.