From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751319AbcCHW2d (ORCPT ); Tue, 8 Mar 2016 17:28:33 -0500 Received: from down.free-electrons.com ([37.187.137.238]:54857 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750802AbcCHW2Y (ORCPT ); Tue, 8 Mar 2016 17:28:24 -0500 Date: Tue, 8 Mar 2016 23:28:21 +0100 From: Maxime Ripard To: Andrey Smirnov Cc: Srinivas Kandagatla , linux-kernel@vger.kernel.org, Sascha Hauer , Trent Piepho Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Message-ID: <20160308222821.GL8418@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lRMsAdG4hjP4MFkn" Content-Disposition: inline In-Reply-To: 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 --lRMsAdG4hjP4MFkn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Mar 07, 2016 at 08:07:41PM -0800, Andrey Smirnov wrote: > >> > > >> > Patch itself looks simple. Before we review it further could you pro= vide > >> > more details on the exact usecase or some background of this. > >> > >> The discussion on this topic originated on mailing list of Barebox > >> project(which borrows very heavily from Linux designs). Barebox > >> operates on two device tree blobs, one is used for its internal > >> initialization, whereas second one is passed to Linux kernel when > >> booting it. The problem I was trying to solve was to make possible to > >> specify in the first DT blob what data would be used for MAC address > >> fixup of the second DT blob(the one passed to Linux). > >> > >> My first approach was to implement a very limited DT code, however in > >> discussing it the consensus was that porting 'nvmem' subsystem from > >> the kernel and using for the same purpose would be a better approach. > >> First pass adoption of that subsystem revealed that there were two > >> use-cases that current design didn't allow us to handle: > >> > >> - Depending on the version i.MX SoC MAC address data stored in ROM > >> would have different layout so as a possible solution to that I > >> implemented "composite" driver(patch #3) > >> > >> - On i.MX28, part of the MAC address is hard-coded in > >> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from > >> ROM, this patch in combination with the aforementioned one should > >> allow us to encode all needed info in DT. > >> > >> Ideally, since all of the above is as applicable to Linux as it is to > >> Barebox it would be good for BB not to invent its own custom 'nvmem' > >> flavor, so hence me trying to start a conversation about adding this > >> upstream. > > > > If the only use-case is to store the MAC address, why not using the > > local-mac-address property directly? >=20 > 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? > 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. It's already what U-Boot does here for example (the source of ethaddr being dependent of the platform): http://git.denx.de/?p=3Du-boot.git;a=3Dblob;f=3Dcommon/fdt_support.c#l468 Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --lRMsAdG4hjP4MFkn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW31IFAAoJEBx+YmzsjxAgL3gQAIHpid29p4jVLjBeqx3/UQ4Q Ly5Pv5OqDIDhW9/PqDVE76gTk2q/8zyKVr3J6egFDR7STS+jx72U3acLB9ukZpKw v9Sr4RNizt8CAbJxeLHKJcke14wIX2ydE13POD/noyM9PUmERECD2DdfzHZO5rLL 2XbWKcs+GB2v3JsYKQZ1WdDF8xobribPXbxajqCtVw4yTVyiPYL4Ue0ylC5qJk5H 6uX2a67pT2fvao4jFD5eIXOx3ZEG3/EwBPsmjM5kR3h8Lhsnn10KmOWyR/2BE/ST 6ctQlQpsWyIZfhRFPbQehdDhs6KKBmAf19mIj3yJCjYMzKDBrG1rqGXXkLBnLA+o 2ZBzgS05InF8mzrcLIY8cTdnW6hBiGlejvYt5rBCPj9K6BXbTqbL3k03gJhlbpLP KGJAa08HiZ7ltOj6GeuX9e3BzH1trzj2z/tFKaJZ4PaNAMsRXcVXDc7IrtYFEHK9 cSzYLuiLhL3+nJdcwmSLnDGinbsaUjl06bJ5LGmd6X8Xp3fvEcfno6VIJi/mXpDC 3YDOJ2w+y9ArqOS6JBRsET4PK326FHTDLDmHE3dOU7TDlxLNbe58p68bPv73DBSv snSeKzYiE2NG9qgb0UNwvcF4pVovND12gfxb2/e1nXBU9CdTj6ig/ZmVEINVpvsm CBKopLrzOnnfoVvTYXOf =DhQa -----END PGP SIGNATURE----- --lRMsAdG4hjP4MFkn--