From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28AD4C4321D for ; Sun, 19 Aug 2018 11:32:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D33B12151C for ; Sun, 19 Aug 2018 11:32:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D33B12151C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=free.fr Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726496AbeHSOnj (ORCPT ); Sun, 19 Aug 2018 10:43:39 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:41244 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725885AbeHSOnj (ORCPT ); Sun, 19 Aug 2018 10:43:39 -0400 Received: from tock (unknown [88.130.57.217]) (Authenticated sender: albeu) by smtp5-g21.free.fr (Postfix) with ESMTPSA id 541C25FFAC; Sun, 19 Aug 2018 13:31:09 +0200 (CEST) Date: Sun, 19 Aug 2018 13:31:06 +0200 From: Alban To: Boris Brezillon Cc: Aban Bedel , Bartosz Golaszewski , Jonathan Corbet , Sekhar Nori , Kevin Hilman , Russell King , Arnd Bergmann , Greg Kroah-Hartman , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Grygorii Strashko , "David S . Miller" , Srinivas Kandagatla , Naren , Mauro Carvalho Chehab , Andrew Morton , Lukas Wunner , Dan Carpenter , Florian Fainelli , Ivan Khoronzhuk , Sven Van Asbroeck , Paolo Abeni , Rob Herring , David Lechner , Andrew Lunn , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org, netdev@vger.kernel.org, Bartosz Golaszewski Subject: Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API Message-ID: <20180819133106.0420df5f@tock> In-Reply-To: <20180817182720.6a6e5e8e@bbrezillon> References: <20180810080526.27207-1-brgl@bgdev.pl> <20180810080526.27207-7-brgl@bgdev.pl> <20180817182720.6a6e5e8e@bbrezillon> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/TQqb4/k1M=FtYu85dR=ch4z"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/TQqb4/k1M=FtYu85dR=ch4z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 17 Aug 2018 18:27:20 +0200 Boris Brezillon wrote: > Hi Bartosz, >=20 > On Fri, 10 Aug 2018 10:05:03 +0200 > Bartosz Golaszewski wrote: >=20 > > From: Alban Bedel > >=20 > > Allow drivers that use the nvmem API to read data stored on MTD devices. > > For this the mtd devices are registered as read-only NVMEM providers. > >=20 > > Signed-off-by: Alban Bedel > > [Bartosz: > > - use the managed variant of nvmem_register(), > > - set the nvmem name] > > Signed-off-by: Bartosz Golaszewski =20 >=20 > What happened to the 2 other patches of Alban's series? I'd really > like the DT case to be handled/agreed on in the same patchset, but > IIRC, Alban and Srinivas disagreed on how this should be represented. > I hope this time we'll come to an agreement, because the MTD <-> NVMEM > glue has been floating around for quite some time... These other patches were to fix what I consider a fundamental flaw in the generic NVMEM bindings, however we couldn't agree on this point. Bartosz later contacted me to take over this series and I suggested to just change the MTD NVMEM binding to use a compatible string on the NVMEM cells as an alternative solution to fix the clash with the old style MTD partition. However all this has no impact on the code needed to add NVMEM support to MTD, so the above patch didn't change at all. Alban --Sig_/TQqb4/k1M=FtYu85dR=ch4z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJbeVT7AAoJEHSUmkuduC28SdMP/3+kDayzSjsABxnvDQU4p5lQ NA13kysUhSl4DlckghrBsgoq9/Jwg+jFjOWflojpHLDKAWpQyzZQU/pd+M99JorF StfVexTlBJqB0gz0wOktfK2XCspxhXSlUa5oWKPDdvVPPNNdVDhfNaQXo6m1SWPg DH4Dqmc58UUX0VtLVjPscQLECINAbhvb0T6axgnyev7GXhoV8BJGZs9D+Ap3MAUW afsXgaAOaQ8W8W14m8KJ3FsJnj78vXVKoZSbWDvhAt67gt8nN/7SMtEx/vT1ceYD vlaWHNMi/6Vsx4SsrdfP2OD9mjj17J61UFjtdXgJDLMgX+Xligr+/uGJSYSCXCwD skxKnfs9B391RVeH76q1fIFE1sTBNTO7/3uwl9zF5vDKoPrLtVEu8RpN0SDxZMHJ qQy05vA8FoG33IeUAUQ0URiDHH9BaYOmMT735CCtsJD2lujQWU93MXIgb7/5lb0u FzYH5lpWnqeP8NJnLplr9g2LG7ucE4IjUoKjp5OHEwv798HWUILmCK4TZRWDwrGx cV7a7p0jXiRgkw5haBA7zs3bjYo0p7k46F+6CZFznQEndOKReOsiYT9kdr53V2qK sjleNX8U24LXgPeTibUkCfDsk2o9vbB0qd07Afc4div8Blm3pUbd/g1XxTdJsv4a zX3GoEXnpt5VB6qK13EN =kqAD -----END PGP SIGNATURE----- --Sig_/TQqb4/k1M=FtYu85dR=ch4z-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alban Subject: Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API Date: Sun, 19 Aug 2018 13:31:06 +0200 Message-ID: <20180819133106.0420df5f@tock> References: <20180810080526.27207-1-brgl@bgdev.pl> <20180810080526.27207-7-brgl@bgdev.pl> <20180817182720.6a6e5e8e@bbrezillon> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/TQqb4/k1M=FtYu85dR=ch4z"; protocol="application/pgp-signature" Cc: Aban Bedel , Bartosz Golaszewski , Jonathan Corbet , Sekhar Nori , Kevin Hilman , Russell King , Arnd Bergmann , Greg Kroah-Hartman , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Grygorii Strashko , "David S . Miller" , Srinivas Kandagatla , Naren , Mauro Carvalho Chehab , Andrew Morton , Lukas Wunner , Dan Carpenter Return-path: Received: from smtp5-g21.free.fr ([212.27.42.5]:41244 "EHLO smtp5-g21.free.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725885AbeHSOnj (ORCPT ); Sun, 19 Aug 2018 10:43:39 -0400 In-Reply-To: <20180817182720.6a6e5e8e@bbrezillon> Sender: netdev-owner@vger.kernel.org List-ID: --Sig_/TQqb4/k1M=FtYu85dR=ch4z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 17 Aug 2018 18:27:20 +0200 Boris Brezillon wrote: > Hi Bartosz, >=20 > On Fri, 10 Aug 2018 10:05:03 +0200 > Bartosz Golaszewski wrote: >=20 > > From: Alban Bedel > >=20 > > Allow drivers that use the nvmem API to read data stored on MTD devices. > > For this the mtd devices are registered as read-only NVMEM providers. > >=20 > > Signed-off-by: Alban Bedel > > [Bartosz: > > - use the managed variant of nvmem_register(), > > - set the nvmem name] > > Signed-off-by: Bartosz Golaszewski =20 >=20 > What happened to the 2 other patches of Alban's series? I'd really > like the DT case to be handled/agreed on in the same patchset, but > IIRC, Alban and Srinivas disagreed on how this should be represented. > I hope this time we'll come to an agreement, because the MTD <-> NVMEM > glue has been floating around for quite some time... These other patches were to fix what I consider a fundamental flaw in the generic NVMEM bindings, however we couldn't agree on this point. Bartosz later contacted me to take over this series and I suggested to just change the MTD NVMEM binding to use a compatible string on the NVMEM cells as an alternative solution to fix the clash with the old style MTD partition. However all this has no impact on the code needed to add NVMEM support to MTD, so the above patch didn't change at all. Alban --Sig_/TQqb4/k1M=FtYu85dR=ch4z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJbeVT7AAoJEHSUmkuduC28SdMP/3+kDayzSjsABxnvDQU4p5lQ NA13kysUhSl4DlckghrBsgoq9/Jwg+jFjOWflojpHLDKAWpQyzZQU/pd+M99JorF StfVexTlBJqB0gz0wOktfK2XCspxhXSlUa5oWKPDdvVPPNNdVDhfNaQXo6m1SWPg DH4Dqmc58UUX0VtLVjPscQLECINAbhvb0T6axgnyev7GXhoV8BJGZs9D+Ap3MAUW afsXgaAOaQ8W8W14m8KJ3FsJnj78vXVKoZSbWDvhAt67gt8nN/7SMtEx/vT1ceYD vlaWHNMi/6Vsx4SsrdfP2OD9mjj17J61UFjtdXgJDLMgX+Xligr+/uGJSYSCXCwD skxKnfs9B391RVeH76q1fIFE1sTBNTO7/3uwl9zF5vDKoPrLtVEu8RpN0SDxZMHJ qQy05vA8FoG33IeUAUQ0URiDHH9BaYOmMT735CCtsJD2lujQWU93MXIgb7/5lb0u FzYH5lpWnqeP8NJnLplr9g2LG7ucE4IjUoKjp5OHEwv798HWUILmCK4TZRWDwrGx cV7a7p0jXiRgkw5haBA7zs3bjYo0p7k46F+6CZFznQEndOKReOsiYT9kdr53V2qK sjleNX8U24LXgPeTibUkCfDsk2o9vbB0qd07Afc4div8Blm3pUbd/g1XxTdJsv4a zX3GoEXnpt5VB6qK13EN =kqAD -----END PGP SIGNATURE----- --Sig_/TQqb4/k1M=FtYu85dR=ch4z-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alban Subject: Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API Date: Sun, 19 Aug 2018 13:31:06 +0200 Message-ID: <20180819133106.0420df5f@tock> References: <20180810080526.27207-1-brgl@bgdev.pl> <20180810080526.27207-7-brgl@bgdev.pl> <20180817182720.6a6e5e8e@bbrezillon> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/TQqb4/k1M=FtYu85dR=ch4z"; protocol="application/pgp-signature" Return-path: In-Reply-To: <20180817182720.6a6e5e8e@bbrezillon> Sender: netdev-owner@vger.kernel.org To: Boris Brezillon Cc: Aban Bedel , Bartosz Golaszewski , Jonathan Corbet , Sekhar Nori , Kevin Hilman , Russell King , Arnd Bergmann , Greg Kroah-Hartman , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Grygorii Strashko , "David S . Miller" , Srinivas Kandagatla , Naren , Mauro Carvalho Chehab , Andrew Morton , Lukas Wunner , Dan Carpenter List-Id: linux-i2c@vger.kernel.org --Sig_/TQqb4/k1M=FtYu85dR=ch4z Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 17 Aug 2018 18:27:20 +0200 Boris Brezillon wrote: > Hi Bartosz, >=20 > On Fri, 10 Aug 2018 10:05:03 +0200 > Bartosz Golaszewski wrote: >=20 > > From: Alban Bedel > >=20 > > Allow drivers that use the nvmem API to read data stored on MTD devices. > > For this the mtd devices are registered as read-only NVMEM providers. > >=20 > > Signed-off-by: Alban Bedel > > [Bartosz: > > - use the managed variant of nvmem_register(), > > - set the nvmem name] > > Signed-off-by: Bartosz Golaszewski =20 >=20 > What happened to the 2 other patches of Alban's series? I'd really > like the DT case to be handled/agreed on in the same patchset, but > IIRC, Alban and Srinivas disagreed on how this should be represented. > I hope this time we'll come to an agreement, because the MTD <-> NVMEM > glue has been floating around for quite some time... These other patches were to fix what I consider a fundamental flaw in the generic NVMEM bindings, however we couldn't agree on this point. Bartosz later contacted me to take over this series and I suggested to just change the MTD NVMEM binding to use a compatible string on the NVMEM cells as an alternative solution to fix the clash with the old style MTD partition. However all this has no impact on the code needed to add NVMEM support to MTD, so the above patch didn't change at all. Alban --Sig_/TQqb4/k1M=FtYu85dR=ch4z Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJbeVT7AAoJEHSUmkuduC28SdMP/3+kDayzSjsABxnvDQU4p5lQ NA13kysUhSl4DlckghrBsgoq9/Jwg+jFjOWflojpHLDKAWpQyzZQU/pd+M99JorF StfVexTlBJqB0gz0wOktfK2XCspxhXSlUa5oWKPDdvVPPNNdVDhfNaQXo6m1SWPg DH4Dqmc58UUX0VtLVjPscQLECINAbhvb0T6axgnyev7GXhoV8BJGZs9D+Ap3MAUW afsXgaAOaQ8W8W14m8KJ3FsJnj78vXVKoZSbWDvhAt67gt8nN/7SMtEx/vT1ceYD vlaWHNMi/6Vsx4SsrdfP2OD9mjj17J61UFjtdXgJDLMgX+Xligr+/uGJSYSCXCwD skxKnfs9B391RVeH76q1fIFE1sTBNTO7/3uwl9zF5vDKoPrLtVEu8RpN0SDxZMHJ qQy05vA8FoG33IeUAUQ0URiDHH9BaYOmMT735CCtsJD2lujQWU93MXIgb7/5lb0u FzYH5lpWnqeP8NJnLplr9g2LG7ucE4IjUoKjp5OHEwv798HWUILmCK4TZRWDwrGx cV7a7p0jXiRgkw5haBA7zs3bjYo0p7k46F+6CZFznQEndOKReOsiYT9kdr53V2qK sjleNX8U24LXgPeTibUkCfDsk2o9vbB0qd07Afc4div8Blm3pUbd/g1XxTdJsv4a zX3GoEXnpt5VB6qK13EN =kqAD -----END PGP SIGNATURE----- --Sig_/TQqb4/k1M=FtYu85dR=ch4z-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: albeu@free.fr (Alban) Date: Sun, 19 Aug 2018 13:31:06 +0200 Subject: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API In-Reply-To: <20180817182720.6a6e5e8e@bbrezillon> References: <20180810080526.27207-1-brgl@bgdev.pl> <20180810080526.27207-7-brgl@bgdev.pl> <20180817182720.6a6e5e8e@bbrezillon> Message-ID: <20180819133106.0420df5f@tock> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 17 Aug 2018 18:27:20 +0200 Boris Brezillon wrote: > Hi Bartosz, > > On Fri, 10 Aug 2018 10:05:03 +0200 > Bartosz Golaszewski wrote: > > > From: Alban Bedel > > > > Allow drivers that use the nvmem API to read data stored on MTD devices. > > For this the mtd devices are registered as read-only NVMEM providers. > > > > Signed-off-by: Alban Bedel > > [Bartosz: > > - use the managed variant of nvmem_register(), > > - set the nvmem name] > > Signed-off-by: Bartosz Golaszewski > > What happened to the 2 other patches of Alban's series? I'd really > like the DT case to be handled/agreed on in the same patchset, but > IIRC, Alban and Srinivas disagreed on how this should be represented. > I hope this time we'll come to an agreement, because the MTD <-> NVMEM > glue has been floating around for quite some time... These other patches were to fix what I consider a fundamental flaw in the generic NVMEM bindings, however we couldn't agree on this point. Bartosz later contacted me to take over this series and I suggested to just change the MTD NVMEM binding to use a compatible string on the NVMEM cells as an alternative solution to fix the clash with the old style MTD partition. However all this has no impact on the code needed to add NVMEM support to MTD, so the above patch didn't change at all. Alban -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: