From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932077AbcCIKN4 (ORCPT ); Wed, 9 Mar 2016 05:13:56 -0500 Received: from down.free-electrons.com ([37.187.137.238]:38626 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752787AbcCIKNm (ORCPT ); Wed, 9 Mar 2016 05:13:42 -0500 Date: Wed, 9 Mar 2016 11:13:39 +0100 From: Maxime Ripard To: Trent Piepho Cc: Andrey Smirnov , Srinivas Kandagatla , "linux-kernel@vger.kernel.org" , Sascha Hauer Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Message-ID: <20160309101339.GN8418@lukather> 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> <1457479515.25961.162.camel@rtred1test09.kymeta.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xp03240ql3JIIXA" Content-Disposition: inline In-Reply-To: <1457479515.25961.162.camel@rtred1test09.kymeta.local> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --+xp03240ql3JIIXA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 08, 2016 at 11:24:33PM +0000, Trent Piepho wrote: > 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 examp= le > > >> 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 tre= e, > > > > > > Well, yeah, but the nvmem-blob is also just an array of bytes embedded > > > into the DT, right? > >=20 > > One is accessible via "nvmem" API and the other one isn't. > >=20 > > > > > >> 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. > >=20 > > 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 >=20 > So I did something that solved this a few years ago for another board > and embedded the data into the local-mac-address property. >=20 > 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. >=20 > The kernel looks for 'mac-address' and then 'local-mac-address', with > the former having precedence. >=20 > 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. I guess another solution would be to deal with that at the driver level. Read the 3 last bytes from the OTP, add the MAC prefix and give that to the net framework without looking it up in the DT. The MAC prefix could even be changed then through a kernel parameter, which is not possible currently. > 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. Is your code / binding doc somewhere for reference ? Thanks, Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --+xp03240ql3JIIXA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW3/dTAAoJEBx+YmzsjxAg8WIP/RtoRM8AlhAbL9OyPlEy1bAI Xx1mWqHgbIyNbJ9J1QSH18OokVZ/nONfi+fCL9hSMzMttJJgzEXcQVrwAsdYfIlr Q+ArtgrXV8StcO/IqbJCvCBKFSU9CEMmwhncso4AHWGIimbBPGF/h0zfTcgPrWsk S9/qSDMLW2Qid0pNkva3rzp9vlsXby6/87zvH89nqziC1khlq3u0iB2l23zXdjcU DfrcQe9t6TxS6T4A0BwVosMARkgS3AaQOEdgyb3uyzn+RcL6HYQHE6D/WoS7BDky rUWmvA1CrsftDyDyElJMj48sd7N2v5kO+99uRjUG82/IgtvlC5fjADlaubowh6N1 bu5LFdBWuKd2KWFLol/s6le+aaIomd8hGYyNMKJmB2LuR4MyhyvD96iygzmX2MGv NkM252m0SoAUoVv8+l3AGFSHzCBTJiHeQebQZ4jIkY9CReFRHO6bY7knWVlzIwfe +AzZuGBv2WpMyebt0RAaWsuqMxH3bsPEFqMphZKNxdMqWgxbncdEh/cgvTRr2HsI NCyw4Xqh6XwV+GNGw1MgC3m5KrpEvstXMhUDRMlS/x5o+uqj76sK0lFXNW2dozrL mp9b9szwyfrYVSIIp/jMrjeazuKrGQndnB4ozTMewmCEwNR5jLZ7AQYn3M3gULC2 8YdO3M1X6FDftd6eiKDo =uPoB -----END PGP SIGNATURE----- --+xp03240ql3JIIXA--