From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Tue, 31 Jul 2018 09:37:20 +0200 Subject: [U-Boot] [PATCH v4 00/27] SPI-NAND support In-Reply-To: References: <20180713123213.23596-1-miquel.raynal@bootlin.com> <20180726092930.7acc0380@xps13> <8bafd3ee-604e-aab8-1f61-8b429439adf8@denx.de> Message-ID: <20180731093720.2b3d4db2@xps13> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi Jagan, Stefan Roese wrote on Tue, 31 Jul 2018 07:50:54 +0200: > Hi Jagan, >=20 > On 31.07.2018 07:36, Jagan Teki wrote: >=20 > >=20 > >>>> Acked--by: Jagan Teki > >>>> =20 > >>> > >>> Thanks! > >>> =20 > >>>> Can you rebase on master and send the needed patches or whole? Look > >>>> like some changes been added in drivers/mtd/nand/Kconfig =20 > >>> > >>> > >>> I'll wait a bit for Stefan review also and I think I missed something > >>> in mtdparts: old partitions are not freed when creating new ones. =20 > > > Is this resolved with v5? =20 Absolutely not, but I will fix it in a next series during the stabilization cycle. Maybe I will rework a bit mtdparts too, to trash the thin layer that handles the partitions to use in a much more consistent way the MTD core. > > >> =20 > >> I'm back from vacation and am starting to work on this SPI NAND > >> support again. Right now, I'm facing a problem with 32 Bytes > >> missing when written to NAND and read back. Most likely a problem > >> with my SPI driver which supports a maximum of 32 Bytes per SPI > >> message (I'm using adjust_op_size() to adjust the max xfer size). > > > Is it with kirkwood? =20 >=20 > No. Its with a new platform I'm currently working on (MediaTek > MT7688 MIPS) - custom board. The platform and board port will be > posted in a few days / weeks (once its ready). >=20 > >> As for waiting for my review comments, I would suggest to pull > >> this patchset (once updated onto TOT) soon, as the merge window > >> closes just today. We can fix issues later in this release cycle. > >> Otherwise we need to postpone this series to the next release, which > >> is of course also on option. > > > If the issue is generic and it changed the current behavior on mtd or= =20 > > any other related areas, it's better to hold. =20 >=20 > AFAICT its not generic. The SPI NAND seems to be working for Miquel > and its a new infrastructure. So chances for breaking an existing > board / platform are pretty low. I totally agree on this. > By pulling this patchset now, we > enable the possibility for implementing and testing it on other > platforms sooner. Tom also seems to be willing to do so. Jagan, I just saw your answer to the cover letter of the v5, thanks for applying it. Regards, Miqu=C3=A8l