From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 31 May 2013 16:44:45 -0500 Subject: [U-Boot] Pull request: nand flash In-Reply-To: <20130531212841.GU11917@bill-the-cat> (from trini@ti.com on Fri May 31 16:28:41 2013) Message-ID: <1370036685.13614.16@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 05/31/2013 04:28:41 PM, Tom Rini wrote: > On Fri, May 31, 2013 at 02:52:17PM -0500, Scott Wood wrote: > > > The following changes since commit > 8bcb6f43e98ffc76e998349e0ec32a0e359160d4: > > > > Update MAINTAINERS file for sandbox (2013-05-17 17:04:39 -0400) > > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-nand-flash.git master > > > > for you to fetch changes up to > f3e9d53b5f35472745077b072399aefe87f228d4: > > > > mtd: resync with Linux-3.7.1 (2013-05-30 15:25:39 -0500) > > > > ---------------------------------------------------------------- > > Harvey Chapman (1): > > nand: adjust erase/read/write partition/chip size for bad > blocks > > > > Prabhakar Kushwaha (1): > > nand/fsl_ifc: Convert to self-init > > > > Scott Wood (1): > > nand/fsl_elbc: detect page size at runtime > > > > Sergey Lapin (1): > > mtd: resync with Linux-3.7.1 > > > > htbegin (2): > > mtd: nand: fix the partial page write condition > > mtd: nand: use ssize_t instead of size_t to prevent infinite > loop > > > > board/ait/cam_enc_4xx/cam_enc_4xx.c | 12 +- > > common/cmd_nand.c | 53 +- > > common/cmd_onenand.c | 30 +- > > common/env_onenand.c | 6 +- > > drivers/mtd/Makefile | 4 +- > > drivers/mtd/cfi_mtd.c | 12 +- > > drivers/mtd/mtdconcat.c | 98 +-- > > drivers/mtd/mtdcore.c | 191 ++++ > > drivers/mtd/mtdpart.c | 158 ++-- > > drivers/mtd/nand/atmel_nand.c | 17 +- > > drivers/mtd/nand/bfin_nand.c | 2 + > > drivers/mtd/nand/davinci_nand.c | 4 +- > > drivers/mtd/nand/diskonchip.c | 13 +- > > drivers/mtd/nand/fsl_elbc_nand.c | 56 +- > > drivers/mtd/nand/fsl_ifc_nand.c | 62 +- > > drivers/mtd/nand/fsmc_nand.c | 5 +- > > drivers/mtd/nand/jz4740_nand.c | 1 + > > drivers/mtd/nand/mpc5121_nfc.c | 2 +- > > drivers/mtd/nand/mxc_nand.c | 25 +- > > drivers/mtd/nand/mxs_nand.c | 34 +- > > drivers/mtd/nand/nand_base.c | 1658 > ++++++++++++++++++++--------------- > > drivers/mtd/nand/nand_bbt.c | 822 ++++++++--------- > > drivers/mtd/nand/nand_ids.c | 14 +- > > drivers/mtd/nand/nand_util.c | 26 +- > > drivers/mtd/nand/ndfc.c | 1 + > > drivers/mtd/nand/nomadik.c | 1 + > > drivers/mtd/nand/omap_gpmc.c | 6 +- > > drivers/mtd/nand/s3c2410_nand.c | 1 + > > drivers/mtd/nand/tegra_nand.c | 27 +- > > drivers/mtd/nand/tegra_nand.h | 2 +- > > drivers/mtd/onenand/onenand_base.c | 82 +- > > drivers/mtd/onenand/onenand_bbt.c | 6 +- > > drivers/mtd/ubi/build.c | 2 +- > > drivers/mtd/ubi/eba.c | 2 +- > > drivers/mtd/ubi/io.c | 12 +- > > drivers/mtd/ubi/kapi.c | 2 +- > > drivers/mtd/ubi/misc.c | 2 +- > > drivers/mtd/ubi/vtbl.c | 2 +- > > fs/yaffs2/yaffs_mtdif.c | 18 +- > > fs/yaffs2/yaffs_mtdif2.c | 14 +- > > include/configs/P1022DS.h | 2 - > > include/linux/mtd/bbm.h | 49 +- > > include/linux/mtd/mtd-abi.h | 158 ---- > > include/linux/mtd/mtd.h | 203 +++-- > > include/linux/mtd/nand.h | 173 ++-- > > include/linux/string.h | 3 + > > include/nand.h | 11 +- > > lib/string.c | 59 ++ > > 48 files changed, 2255 insertions(+), 1888 deletions(-) > > delete mode 100644 include/linux/mtd/mtd-abi.h > > NAK. Almost everything is blowing up with: > /home/trini/work/u-boot/u-boot/include/linux/mtd/mtd.h:12:25: fatal > error: mtd/mtd-abi.h: No such file or directory compilation > terminated. Sigh. It's present locally, but didn't get added to the commit for some reason. I hate how "git am" operates in the presence of rejects, even when the --reject option is given. Given how recently it was pushed, should I amend the commit (to preserve bisectability) or make a followup patch? > Which tells me this can't have had much / any run-time testing, which > I'm not super comfortable on, with a re-sync of the subsystem. I doubt many people use u-boot-nand-flash.git directly, so you're never going to get much *run-time* testing prior to a merge, beyond what I do personally on a board or two. -Scott