From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752263AbcCGISv (ORCPT ); Mon, 7 Mar 2016 03:18:51 -0500 Received: from down.free-electrons.com ([37.187.137.238]:59770 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752046AbcCGISp (ORCPT ); Mon, 7 Mar 2016 03:18:45 -0500 Date: Mon, 7 Mar 2016 09:18:42 +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: <20160307081842.GA8418@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DuNoGD3ogd33HnLq" 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 --DuNoGD3ogd33HnLq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Mar 02, 2016 at 09:21:01AM -0800, Andrey Smirnov wrote: > On Wed, Mar 2, 2016 at 5:58 AM, Srinivas Kandagatla > wrote: > > > > > > On 01/03/16 16:59, Andrey Smirnov wrote: > >> > >> Add 'nvmem-blob' driver, which allows to access device tree embedded > >> data via NVMEM subsystem API. > > > > > > Patch itself looks simple. Before we review it further could you provide > > more details on the exact usecase or some background of this. >=20 > 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). >=20 > 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: >=20 > - 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) >=20 > - 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. >=20 > 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? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --DuNoGD3ogd33HnLq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW3TliAAoJEBx+YmzsjxAgnykP+gOAVOKpiD6m+dpUmGtyUtXj ZWhHHtD9Tlj1FdpGCI2674DBf8WiGMMNBI3uMeAT1aXfjtixlVxsI/Wd3Q9Bha01 LdzuyHdYZeBAZ5A/xrxSwJb6DSTVHlbfGlx81jvJtIkFFSZhwWnHyGWRKTg3sXLg Ad9nBW8kU7foqbL+pOcybruc2D3usEGyFFmHtVPqG3sp0Pgb4RVeCSiFuPAtW2u2 YQMWt3yXH5peOWFUKOZsBut2h3pszd72rzNwt+ucIVOfNTMD64qYkkeNG/nZAKC0 O3xULgLDNDWTp2XJvwM3gR+IQ3fq+T5qV82I3Xm2AJV+WLmkHB6mx94jvDGp6VRZ EpmDE3bgh+7i0zDADQB3cBPqR13RwQbyD/5cCJ+Hmzy6yLbaBvcoLNrfqRmZJrVi OVtBcDFQtVl+Oq8gUx6Tw9qHvnd8a+ZJIYjCS/ylt9wmU0nGrWcugSKP/9XNCzBN Ky+bStB5TDgmWleeUcg0L/EsJiJ3BGktdRNdX9f/O7ZWoSW23HlX2/LB+8V6K272 98WGzA+1CQS182i1xDyhU07cnXrXouwylyWKF+4tYVTeWW0BrppAn7j2hOWCMIfU c95TSRCb7WZ6IlG0ElDHjMvM7p1y47I1IxFqDwJRRJ4y3a4PLN7ElBUAvlswVL9f Up6KguQ1nDAqGAWumQyJ =PQ1Z -----END PGP SIGNATURE----- --DuNoGD3ogd33HnLq--