From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20181203091456.454030-1-tmaimon77@gmail.com> <20181203102240.79a86a26@bbrezillon> <20181203153046.0554854f@bbrezillon> In-Reply-To: <20181203153046.0554854f@bbrezillon> From: Tomer Maimon Date: Mon, 3 Dec 2018 17:28:23 +0200 Message-ID: Subject: Re: [PATCH v1 0/2] SPI-NOR add NPCM FIU controller driver Content-Type: multipart/alternative; boundary="000000000000956a47057c1fb59a" To: boris.brezillon@bootlin.com Cc: David Woodhouse , computersforpeace@gmail.com, marek.vasut@gmail.com, richard@nod.at, Rob Herring , Mark Rutland , Nancy Yuen , Patrick Venture , Brendan Higgins , Avi Fishman , Joel Stanley , linux-mtd@lists.infradead.org, OpenBMC Maillist , Linux Kernel Mailing List , devicetree List-ID: --000000000000956a47057c1fb59a Content-Type: text/plain; charset="UTF-8" Hi Boris, Thanks for your prompt reply, We will start to work on it soon. Regards, Tomer On Mon, 3 Dec 2018 at 16:30, Boris Brezillon wrote: > Hi Tomer; > > On Mon, 3 Dec 2018 16:09:19 +0200 > Tomer Maimon wrote: > > > > A few comments/input: > > > > > > 1. We have been working on this driver for quite a long time to port > it > > to the latest Linux conventions, polish the code, run tests and reach > high > > quality. > > Our partners and customers are waiting to get this driver upstream so > > they can freely use it. > > Your patch prefix says "v1", so I'm assuming this is the first public > version. I'm sure you spent a lot of time developing this driver > internally, but no matter how long it took, it's a first version for > us, and since we are moving away from the spi_nor controller interface, > I'm not willing to accept new drivers using this interface. > > If you want more background about the spi_nor controller interface > deprecation, you can read [1]. > > > Since this driver is already in final stages and is in very good shape > > we will appreciate if you can review this specific driver/interface > and > > help us to upstream it. > > Actually, I'd like to do it the other way around: let you rework the > driver to implement the spi-mem interface and review this version. > Otherwise I'll be reviewing things I don't intend to merge anyway. > > > 2. As for the new interface, we are open for any discussion and for > > porting the driver as required. > > We are unsure what is this specific interface and weather it really > fits > > a driver for a Flash Interface Controller module (rather than a SPI > flash > > device). > > Didn't go through the code in details, but at first glance, it looks > like it would fit pretty well. > > > Is it possible to get a sample driver from another Flash Interface > > Controller module that was ported to this new interface ? > > We recently converted the atmel QSPI driver [2]. > > Regards, > > Boris > > [1] > https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ > [2] > https://patchwork.kernel.org/project/spi-devel-general/list/?series=38347&state=* > --000000000000956a47057c1fb59a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Boris,

Thanks for your prompt=C2=A0r= eply,

We will start to work on it soon.
=
Regards,

Tomer

On Mon, 3 Dec 2018 at 16:30, Boris B= rezillon <boris.brezillon= @bootlin.com> wrote:
Hi Tome= r;

On Mon, 3 Dec 2018 16:09:19 +0200
Tomer Maimon <t= maimon77@gmail.com> wrote:


> A few comments/input:
>
>
>=C2=A0 =C2=A0 1. We have been working on this driver for quite a long t= ime to port it
>=C2=A0 =C2=A0 to the latest Linux conventions, polish the code, run tes= ts and reach high
>=C2=A0 =C2=A0 quality.
>=C2=A0 =C2=A0 Our partners and customers are waiting to get this driver= upstream so
>=C2=A0 =C2=A0 they can freely use it.

Your patch prefix says "v1", so I'm assuming this is the firs= t public
version. I'm sure you spent a lot of time developing this driver
internally, but no matter how long it took, it's a first version for us, and since we are moving away from the spi_nor controller interface,
I'm not willing to accept new drivers using this interface.

If you want more background about the spi_nor controller interface
deprecation, you can read [1].

>=C2=A0 =C2=A0 Since this driver is already in final stages and is in ve= ry good shape
>=C2=A0 =C2=A0 we will appreciate if you can review this specific driver= /interface and
>=C2=A0 =C2=A0 help us to upstream it.

Actually, I'd like to do it the other way around: let you rework the driver to implement the spi-mem interface and review this version.
Otherwise I'll be reviewing things I don't intend to merge anyway.<= br>
>=C2=A0 =C2=A0 2.=C2=A0 As for the new interface, we are open for any di= scussion and for
>=C2=A0 =C2=A0 porting the driver as required.
>=C2=A0 =C2=A0 We are unsure what is this specific interface and weather= it really fits
>=C2=A0 =C2=A0 a driver for a Flash Interface Controller module (rather = than a SPI flash
>=C2=A0 =C2=A0 device).

Didn't go through the code in details, but at first glance, it looks like it would fit pretty well.

>=C2=A0 =C2=A0 Is it possible to get a sample driver from another Flash = Interface
>=C2=A0 =C2=A0 Controller module that was ported to this new interface ?=

We recently converted the atmel QSPI driver [2].

Regards,

Boris

[1]https://bo= otlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosyste= m/
[2]https://= patchwork.kernel.org/project/spi-devel-general/list/?series=3D38347&sta= te=3D*
--000000000000956a47057c1fb59a--