Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752547AbbFYRuO (ORCPT ); Thu, 25 Jun 2015 13:50:14 -0400 Received: from down.free-electrons.com ([37.187.137.238]:55902 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751370AbbFYRuJ (ORCPT ); Thu, 25 Jun 2015 13:50:09 -0400 Date: Thu, 25 Jun 2015 19:49:13 +0200 From: Maxime Ripard To: Srinivas Kandagatla Cc: Sanchayan Maity , linux-arm-kernel@lists.infradead.org, arnd@arndb.de, linux-kernel@vger.kernel.org, stefan@agner.ch, kernel@pengutronix.de, shawn.guo@linaro.org Subject: Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support Message-ID: <20150625174913.GG2266@lukather> References: <20150624083529.GY2266@lukather> <558A79B3.1010205@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yxUjl2uTvAeSG6i1" Content-Disposition: inline In-Reply-To: <558A79B3.1010205@linaro.org> 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 Content-Length: 3447 Lines: 94 --yxUjl2uTvAeSG6i1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jun 24, 2015 at 10:34:43AM +0100, Srinivas Kandagatla wrote: >=20 >=20 > On 24/06/15 09:35, Maxime Ripard wrote: > >Hi, > > > >On Tue, Jun 23, 2015 at 07:14:57PM +0530, Sanchayan Maity wrote: > >>+static struct nvmem_config ocotp_config =3D { > >>+ .name =3D "soc_id", > >>+}; > >>+ > >>+static struct nvmem_config rom_config =3D { > >>+ .name =3D "rom_rev", > >>+}; > > > >Srinivas, shouldn't we use the DT to setup these names, just like > >clock-output-names does for example? > > These are the provider names, which would not change per board, I > think. :-) Except that my understanding is that it will fallback to the list of these names if there's nothing in the DT. > On the other hand if we are going to use generic drivers like > "simple-mmio-nvmem" then having name DT bindings makes sense. >=20 > IMO, clock-output-names are analogous to nvmem consumers, which are > obviously getting there names from cell node name ATM. clock-output-names is the name of the clock itself within the system. clock-names is the name of the clock to the consumer. So, it looks like nvmem-names is strictly equivalent to clock-names (local to the device, doesn't affect the name of the provider within in the system) which makes perfect sense, but we don't really have an equivalent to clock-output-names but this one (global range, defines the name of the provider globally), which is fine for specific devices, whose format and functions are very standardized, like those EEPROMs, but is not so much for other more generic devices, like the mmio-nvmem driver you were talking about, or ... > >This is very likely to change from one board to another, and defining > >a new compatible and/or driver for each board seems a bit fishy. > > > Do you have any particular example in mind, where the provider names would > change per board? =2E.. AT24, AT25, and all those generic, off-the-SoC EEPROMs, where each board vendor is pretty much free to do whatever he wants with it. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --yxUjl2uTvAeSG6i1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVjD8ZAAoJEBx+YmzsjxAgkxQQALPjdt+wJ1RQdlDFmQ9T4yum gPPKOBtGgiKeB5pyL1XXQ22LdjAhjx4LSkUv0JukjeLrS1GnFH6hgExpZnX2mXL4 qfea04CJcASlo0EUZVWCGQtBTnM4HWqdX3YdKgDYz4gww4roU66OzZyGfYAMUHbx wKdaj85wTp/jqTigclJcqi5ITzezhFoiuPm4rv4c3Ssg9hSYMyv5EVF6GnLz40IT Am081jjtMZc7akJtMVqIz6kQRDYGeOG56EIyhyRk3/YilQKaMWrj8vw/IjokMSPK vKY8MGDgThZkieqC+HHeOoruf6MN2qjuYEuUrXk6yTRimKQQ5rjAc04/RZr3fFOX ah9PkBJpD6A+/xverMoMyjdNFQZ8NB7G1Lu/JjIk281YgfZR4qoGrBkMJd16AwI1 O4g4o4UC4FWzKA0O7u1HfVpcKaCkk5djPP9fJd1nDdBgVi7kjS0gV4CMFN00LbdP CP8x6uNMsHilWkqACFL7KMe87I0zPEsRtwNYfx+mc49GQjZvc5y2JSv5obf8cD+o zEdm+ZAyLaqrtQ8HWIMX9dC3qsQVqy7rMkC7n6UUCzXxbDSwMKknKULBwuUfFIKN es2T55dE/0Ka8GbtV8dbI5k5GwGS66yR8RXGQM1GUw6thN4JF2s8HGWxynzldoVg pxylDY1StBpPZ+OLe+M8 =4YFr -----END PGP SIGNATURE----- --yxUjl2uTvAeSG6i1-- -- 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/