Re: [upstream] mtd/ifc: fix ifc driver memory release issue
On Thu, 2013-03-28 at 21:28 -0700, Brian Norris wrote: On Wed, Mar 27, 2013 at 5:25 AM, Roy Zang tie-fei.z...@freescale.com wrote: memory is allocated by devm_kzalloc, so release it using devm_kfree() instead kfree(); You are correct that it should not be freed with kfree(). But the correct solution is that it does not need to be freed (explicitly) at all. That's the whole point of the managed allocators (i.e., devm_kzalloc()). Try this patch instead. Totally untested here. Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/10] mtd: remove dead map drivers
[Adding the PPC list] This patch-set removes a bunch of dean MTD map drivers. The way I judged whether a driver is dead or not was looking at driver's dependencies in the Kconfig file. Whenever I saw a driver depending on a Kconfig symbol which is not defined anywhere, I treated the driver as dead. The motivation for this patch-set is to clean up the MTD subsystem a little and lessen the maintenance burden. Indeed, the less drivers we have, the easier it is to do MTD framework refactoring. Thanks, Artem. __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/10] mtd: remove the dbox2-flash map driver
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
This driver depends on the CONFIG_DBOX2 symbol which does not exist in
the kernel, which means the driver is dead.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
Adding the PPC list
drivers/mtd/maps/Kconfig |8 ---
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps/dbox2-flash.c | 123
3 files changed, 132 deletions(-)
delete mode 100644 drivers/mtd/maps/dbox2-flash.c
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 3ed17c4..74fe0c2 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -302,14 +302,6 @@ config MTD_MBX860
MBX860 board. If you have one of these boards and would like
to use the flash chips on it, say 'Y'.
-config MTD_DBOX2
- tristate CFI Flash device mapped on D-Box2
- depends on DBOX2 MTD_CFI_INTELSTD MTD_CFI_INTELEXT
MTD_CFI_AMDSTD
- help
- This enables access routines for the flash chips on the Nokia/Sagem
- D-Box 2 board. If you have one of these boards and would like to use
- the flash chips on it, say 'Y'.
-
config MTD_CFI_FLAGADM
tristate CFI Flash device mapping on FlagaDM
depends on 8xx MTD_CFI
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 4ded287..93f4db2 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -34,7 +34,6 @@ obj-$(CONFIG_MTD_TS5500) += ts5500_flash.o
obj-$(CONFIG_MTD_SUN_UFLASH) += sun_uflash.o
obj-$(CONFIG_MTD_VMAX) += vmax301.o
obj-$(CONFIG_MTD_SCx200_DOCFLASH)+= scx200_docflash.o
-obj-$(CONFIG_MTD_DBOX2)+= dbox2-flash.o
obj-$(CONFIG_MTD_SOLUTIONENGINE)+= solutionengine.o
obj-$(CONFIG_MTD_PCI) += pci.o
obj-$(CONFIG_MTD_AUTCPU12) += autcpu12-nvram.o
diff --git a/drivers/mtd/maps/dbox2-flash.c b/drivers/mtd/maps/dbox2-flash.c
deleted file mode 100644
index 85bdece..000
--- a/drivers/mtd/maps/dbox2-flash.c
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * D-Box 2 flash driver
- */
-
-#include linux/module.h
-#include linux/types.h
-#include linux/kernel.h
-#include linux/init.h
-#include asm/io.h
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-#include linux/errno.h
-
-/* partition_info gives details on the logical partitions that the split the
- * single flash device into. If the size if zero we use up to the end of the
- * device. */
-static struct mtd_partition partition_info[]= {
- {
- .name = BR bootloader,
- .size = 128 * 1024,
- .offset = 0,
- .mask_flags = MTD_WRITEABLE
- },
- {
- .name = FLFS (U-Boot),
- .size = 128 * 1024,
- .offset = MTDPART_OFS_APPEND,
- .mask_flags = 0
- },
- {
- .name = Root (SquashFS),
- .size = 7040 * 1024,
- .offset = MTDPART_OFS_APPEND,
- .mask_flags = 0
- },
- {
- .name = var (JFFS2),
- .size = 896 * 1024,
- .offset = MTDPART_OFS_APPEND,
- .mask_flags = 0
- },
- {
- .name = Flash without bootloader,
- .size = MTDPART_SIZ_FULL,
- .offset = 128 * 1024,
- .mask_flags = 0
- },
- {
- .name = Complete Flash,
- .size = MTDPART_SIZ_FULL,
- .offset = 0,
- .mask_flags = MTD_WRITEABLE
- }
-};
-
-#define NUM_PARTITIONS ARRAY_SIZE(partition_info)
-
-#define WINDOW_ADDR 0x1000
-#define WINDOW_SIZE 0x80
-
-static struct mtd_info *mymtd;
-
-
-struct map_info dbox2_flash_map = {
- .name = D-Box 2 flash memory,
- .size = WINDOW_SIZE,
- .bankwidth = 4,
- .phys = WINDOW_ADDR,
-};
-
-static int __init init_dbox2_flash(void)
-{
- printk(KERN_NOTICE D-Box 2 flash driver (size-0x%X
mem-0x%X)\n, WINDOW_SIZE, WINDOW_ADDR);
- dbox2_flash_map.virt = ioremap(WINDOW_ADDR, WINDOW_SIZE);
-
- if (!dbox2_flash_map.virt) {
- printk(Failed to ioremap\n);
- return -EIO;
- }
- simple_map_init(dbox2_flash_map);
-
- // Probe for dual Intel 28F320 or dual AMD
- mymtd = do_map_probe(cfi_probe, dbox2_flash_map);
- if (!mymtd) {
- // Probe for single Intel 28F640
- dbox2_flash_map.bankwidth = 2;
-
- mymtd = do_map_probe(cfi_probe, dbox2_flash_map);
- }
-
- if (mymtd) {
- mymtd-owner = THIS_MODULE;
-
-/* Create MTD devices for each partition. */
- mtd_device_register(mymtd, partition_info, NUM_PARTITIONS);
-
- return 0;
- }
-
- iounmap((void *)dbox2_flash_map.virt);
- return -ENXIO;
-}
-
-static void __exit
[PATCH 02/10] mtd: remove the dmv182 map driver
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
This driver depends on the CONFIG_DMV182 symbol which is not defined anywhere,
and this means that this driver is dead.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
Adding the PPC list
drivers/mtd/maps/Kconfig |9 ---
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps/dmv182.c | 146 -
3 files changed, 156 deletions(-)
delete mode 100644 drivers/mtd/maps/dmv182.c
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 74fe0c2..7071486 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -425,15 +425,6 @@ config MTD_UCLINUX
help
Map driver to support image based filesystems for uClinux.
-config MTD_DMV182
-tristate Map driver for Dy-4 SVME/DMV-182 board.
-depends on DMV182
- select MTD_MAP_BANK_WIDTH_32
- select MTD_CFI_I8
- select MTD_CFI_AMDSTD
-help
- Map driver for Dy-4 SVME/DMV-182 board.
-
config MTD_INTEL_VR_NOR
tristate NOR flash on Intel Vermilion Range Expansion Bus CS0
depends on PCI
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 93f4db2..819e2ab 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -44,7 +44,6 @@ obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
obj-$(CONFIG_MTD_H720X)+= h720x-flash.o
obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o
obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
-obj-$(CONFIG_MTD_DMV182) += dmv182.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
diff --git a/drivers/mtd/maps/dmv182.c b/drivers/mtd/maps/dmv182.c
deleted file mode 100644
index 6538ac6..000
--- a/drivers/mtd/maps/dmv182.c
+++ /dev/null
@@ -1,146 +0,0 @@
-
-/*
- * drivers/mtd/maps/dmv182.c
- *
- * Flash map driver for the Dy4 SVME182 board
- *
- * Copyright 2003-2004, TimeSys Corporation
- *
- * Based on the SVME181 flash map, by Tom Nelson, Dot4, Inc. for TimeSys Corp.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include linux/module.h
-#include linux/init.h
-#include linux/types.h
-#include linux/kernel.h
-#include asm/io.h
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-#include linux/errno.h
-
-/*
- * This driver currently handles only the 16MiB user flash bank 1 on the
- * board. It does not provide access to bank 0 (contains the Dy4 FFW), bank 2
- * (VxWorks boot), or the optional 48MiB expansion flash.
- *
- * scott.w...@timesys.com: On the newer boards with 128MiB flash, it
- * now supports the first 96MiB (the boot flash bank containing FFW
- * is excluded). The VxWorks loader is in partition 1.
- */
-
-#define FLASH_BASE_ADDR 0xf000
-#define FLASH_BANK_SIZE (128*1024*1024)
-
-MODULE_AUTHOR(Scott Wood, TimeSys Corporation scott.w...@timesys.com);
-MODULE_DESCRIPTION(User-programmable flash device on the Dy4 SVME182 board);
-MODULE_LICENSE(GPL);
-
-static struct map_info svme182_map = {
- .name = Dy4 SVME182,
- .bankwidth = 32,
- .size = 128 * 1024 * 1024
-};
-
-#define BOOTIMAGE_PART_SIZE((6*1024*1024)-RESERVED_PART_SIZE)
-
-// Allow 6MiB for the kernel
-#define NEW_BOOTIMAGE_PART_SIZE (6 * 1024 * 1024)
-// Allow 1MiB for the bootloader
-#define NEW_BOOTLOADER_PART_SIZE (1024 * 1024)
-// Use the remaining 9MiB at the end of flash for the RFS
-#define NEW_RFS_PART_SIZE(0x0100 - NEW_BOOTLOADER_PART_SIZE - \
- NEW_BOOTIMAGE_PART_SIZE)
-
-static struct mtd_partition svme182_partitions[] = {
- // The Lower PABS is only 128KiB, but the partition code doesn't
- // like partitions that don't end on the largest erase block
- // size of the device, even if all of the erase blocks in the
- // partition are small ones. The hardware should prevent
- // writes to the actual PABS areas.
- {
- name: Lower PABS and CPU 0 bootloader or kernel,
- size: 6*1024*1024,
- offset: 0,
- },
- {
- name: Root Filesystem,
- size: 10*1024*1024,
- offset: MTDPART_OFS_NXTBLK
- },
- {
- name: CPU1 Bootloader,
- size: 1024*1024,
- offset: MTDPART_OFS_NXTBLK,
- },
- {
- name: Extra,
- size: 110*1024*1024,
- offset: MTDPART_OFS_NXTBLK
- },
- {
- name: Foundation Firmware and Upper PABS,
- size
[PATCH 08/10] mtd: remove the tqm8xxl map driver
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
This driver depends on the CONFIG_TQM8xxL symbol, which is not defined
anywhere, which means that this driver is dead.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
Adding the PPC list
drivers/mtd/maps/Kconfig | 10 --
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps/tqm8xxl.c | 249
3 files changed, 260 deletions(-)
delete mode 100644 drivers/mtd/maps/tqm8xxl.c
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 3fe3216..888e684 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -274,16 +274,6 @@ config MTD_L440GX
BE VERY CAREFUL.
-config MTD_TQM8XXL
- tristate CFI Flash device mapped on TQM8XXL
- depends on MTD_CFI TQM8xxL
- help
- The TQM8xxL PowerPC board has up to two banks of CFI-compliant
- chips, currently uses AMD one. This 'mapping' driver supports
- that arrangement, allowing the CFI probe and command set driver
- code to communicate with the chips on the TQM8xxL board. More at
- http://www.denx.de/wiki/PPCEmbedded/.
-
config MTD_CFI_FLAGADM
tristate CFI Flash device mapping on FlagaDM
depends on 8xx MTD_CFI
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 8e2b289..0cdc881 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_MTD_PHYSMAP_OF) += physmap_of.o
obj-$(CONFIG_MTD_PISMO)+= pismo.o
obj-$(CONFIG_MTD_PMC_MSP_EVM) += pmcmsp-flash.o
obj-$(CONFIG_MTD_PCMCIA) += pcmciamtd.o
-obj-$(CONFIG_MTD_TQM8XXL) += tqm8xxl.o
obj-$(CONFIG_MTD_SA1100) += sa1100-flash.o
obj-$(CONFIG_MTD_SBC_GXX) += sbc_gxx.o
obj-$(CONFIG_MTD_SC520CDP) += sc520cdp.o
diff --git a/drivers/mtd/maps/tqm8xxl.c b/drivers/mtd/maps/tqm8xxl.c
deleted file mode 100644
index d785879..000
--- a/drivers/mtd/maps/tqm8xxl.c
+++ /dev/null
@@ -1,249 +0,0 @@
-/*
- * Handle mapping of the flash memory access routines
- * on TQM8xxL based devices.
- *
- * based on rpxlite.c
- *
- * Copyright(C) 2001 Kirk Lee k...@hpc.ee.ntu.edu.tw
- *
- * This code is GPLed
- *
- */
-
-/*
- * According to TQM8xxL hardware manual, TQM8xxL series have
- * following flash memory organisations:
- * | capacity || chip type | | bank0 | | bank1 |
- * 2MiB 512Kx162MiB 0
- * 4MiB 1Mx16 4MiB 0
- * 8MiB 1Mx16 4MiB 4MiB
- * Thus, we choose CONFIG_MTD_CFI_I2 CONFIG_MTD_CFI_B4 at
- * kernel configuration.
- */
-#include linux/module.h
-#include linux/types.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/slab.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-
-#include asm/io.h
-
-#define FLASH_ADDR 0x4000
-#define FLASH_SIZE 0x0080
-#define FLASH_BANK_MAX 4
-
-// trivial struct to describe partition information
-struct mtd_part_def
-{
- int nums;
- unsigned char *type;
- struct mtd_partition* mtd_part;
-};
-
-//static struct mtd_info *mymtd;
-static struct mtd_info* mtd_banks[FLASH_BANK_MAX];
-static struct map_info* map_banks[FLASH_BANK_MAX];
-static struct mtd_part_def part_banks[FLASH_BANK_MAX];
-static unsigned long num_banks;
-static void __iomem *start_scan_addr;
-
-/*
- * Here are partition information for all known TQM8xxL series devices.
- * See include/linux/mtd/partitions.h for definition of the mtd_partition
- * structure.
- *
- * The *_max_flash_size is the maximum possible mapped flash size which
- * is not necessarily the actual flash size. It must correspond to the
- * value specified in the mapping definition defined by the
- * struct map_desc *_io_desc for the corresponding machine.
- */
-
-/* Currently, TQM8xxL has up to 8MiB flash */
-static unsigned long tqm8xxl_max_flash_size = 0x0080;
-
-/* partition definition for first flash bank
- * (cf. drivers/char/flash_config.c)
- */
-static struct mtd_partition tqm8xxl_partitions[] = {
- {
- .name = ppcboot,
- .offset = 0x,
- .size = 0x0002, /* 128KB */
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- },
- {
- .name = kernel, /* default kernel image */
- .offset = 0x0002,
- .size = 0x000e,
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- },
- {
- .name = user,
- .offset = 0x0010,
- .size = 0x0010,
- },
- {
- .name = initrd,
- .offset = 0x0020,
- .size = 0x0020,
- }
-};
-/* partition definition for second flash bank */
-static struct mtd_partition tqm8xxl_fs_partitions[] = {
- {
- .name = cramfs,
- .offset = 0x,
- .size
[PATCH 09/10] mtd: remove the dilnetpc map driver support
From: Artem Bityutskiy artem.bityuts...@linux.intel.com This driver is marked as broken for very long time. Most probably this board is just something ancient no one cares about anyway. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com --- Adding the PPC list drivers/mtd/maps/Kconfig| 16 -- drivers/mtd/maps/Makefile |1 - drivers/mtd/maps/dilnetpc.c | 496 --- 3 files changed, 513 deletions(-) delete mode 100644 drivers/mtd/maps/dilnetpc.c diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig index 888e684..b6a369a 100644 --- a/drivers/mtd/maps/Kconfig +++ b/drivers/mtd/maps/Kconfig @@ -249,22 +249,6 @@ config MTD_LANTIQ help Support for NOR flash attached to the Lantiq SoC's External Bus Unit. -config MTD_DILNETPC - tristate CFI Flash device mapped on DIL/Net PC - depends on X86 MTD_CFI_INTELEXT BROKEN - help - MTD map driver for SSV DIL/Net PC Boards DNP and ADNP. - For details, see http://www.ssv-embedded.de/ssv/pc104/p169.htm - and http://www.ssv-embedded.de/ssv/pc104/p170.htm - -config MTD_DILNETPC_BOOTSIZE - hex Size of DIL/Net PC flash boot partition - depends on MTD_DILNETPC - default 0x8 - help - The amount of space taken up by the kernel or Etherboot - on the DIL/Net PC flash chips. - config MTD_L440GX tristate BIOS flash chip on Intel L440GX boards depends on X86 MTD_JEDECPROBE diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile index 0cdc881..7315ed8 100644 --- a/drivers/mtd/maps/Makefile +++ b/drivers/mtd/maps/Makefile @@ -9,7 +9,6 @@ endif # Chip mappings obj-$(CONFIG_MTD_CFI_FLAGADM) += cfi_flagadm.o obj-$(CONFIG_MTD_DC21285) += dc21285.o -obj-$(CONFIG_MTD_DILNETPC) += dilnetpc.o obj-$(CONFIG_MTD_L440GX) += l440gx.o obj-$(CONFIG_MTD_AMD76XROM)+= amd76xrom.o obj-$(CONFIG_MTD_ESB2ROM) += esb2rom.o diff --git a/drivers/mtd/maps/dilnetpc.c b/drivers/mtd/maps/dilnetpc.c deleted file mode 100644 index 3e393f0..000 --- a/drivers/mtd/maps/dilnetpc.c +++ /dev/null @@ -1,496 +0,0 @@ -/* dilnetpc.c -- MTD map driver for SSV DIL/Net PC Boards DNP and ADNP - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA - * - * The DIL/Net PC is a tiny embedded PC board made by SSV Embedded Systems - * featuring the AMD Elan SC410 processor. There are two variants of this - * board: DNP/1486 and ADNP/1486. The DNP version has 2 megs of flash - * ROM (Intel 28F016S3) and 8 megs of DRAM, the ADNP version has 4 megs - * flash and 16 megs of RAM. - * For details, see http://www.ssv-embedded.de/ssv/pc104/p169.htm - * and http://www.ssv-embedded.de/ssv/pc104/p170.htm - */ - -#include linux/module.h -#include linux/types.h -#include linux/kernel.h -#include linux/init.h -#include linux/string.h - -#include linux/mtd/mtd.h -#include linux/mtd/map.h -#include linux/mtd/partitions.h -#include linux/mtd/concat.h - -#include asm/io.h - -/* -** The DIL/NetPC keeps its BIOS in two distinct flash blocks. -** Destroying any of these blocks transforms the DNPC into -** a paperweight (albeit not a very useful one, considering -** it only weighs a few grams). -** -** Therefore, the BIOS blocks must never be erased or written to -** except by people who know exactly what they are doing (e.g. -** to install a BIOS update). These partitions are marked read-only -** by default, but can be made read/write by undefining -** DNPC_BIOS_BLOCKS_WRITEPROTECTED: -*/ -#define DNPC_BIOS_BLOCKS_WRITEPROTECTED - -/* -** The ID string (in ROM) is checked to determine whether we -** are running on a DNP/1486 or ADNP/1486 -*/ -#define BIOSID_BASE0x000fe100 - -#define ID_DNPCDNP1486 -#define ID_ADNPADNP1486 - -/* -** Address where the flash should appear in CPU space -*/ -#define FLASH_BASE 0x200 - -/* -** Chip Setup and Control (CSC) indexed register space -*/ -#define CSC_INDEX 0x22 -#define CSC_DATA 0x23 - -#define CSC_MMSWAR 0x30/* MMS window C-F attributes register */ -#define CSC_MMSWDSR0x31/* MMS window C-F device select register */ - -#define CSC_RBWR 0xa7/* GPIO Read-Back/Write Register B */ - -#define CSC_CR 0xd0/* internal I/O device disable
[PATCH 10/10] mtd: remove the ixp2000 map driver
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
This driver depends on CONFIG_IXP2000 which is not defined anywhere, which means
this driver is dead.
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
Adding the PPC list
drivers/mtd/maps/Kconfig |9 --
drivers/mtd/maps/Makefile |1 -
drivers/mtd/maps/ixp2000.c | 253
3 files changed, 263 deletions(-)
delete mode 100644 drivers/mtd/maps/ixp2000.c
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index b6a369a..4b70976 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -297,15 +297,6 @@ config MTD_IXP4XX
IXDP425 and Coyote. If you have an IXP4xx based board and
would like to use the flash chips on it, say 'Y'.
-config MTD_IXP2000
- tristate CFI Flash device mapped on Intel IXP2000 based systems
- depends on MTD_CFI MTD_COMPLEX_MAPPINGS ARCH_IXP2000
- help
- This enables MTD access to flash devices on platforms based
- on Intel's IXP2000 family of network processors. If you have an
- IXP2000 based board and would like to use the flash chips on it,
- say 'Y'.
-
config MTD_AUTCPU12
bool NV-RAM mapping AUTCPU12 board
depends on ARCH_AUTCPU12
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 7315ed8..781e4b8 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -39,7 +39,6 @@ obj-$(CONFIG_MTD_NETtel) += nettel.o
obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
obj-$(CONFIG_MTD_H720X)+= h720x-flash.o
obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o
-obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
diff --git a/drivers/mtd/maps/ixp2000.c b/drivers/mtd/maps/ixp2000.c
deleted file mode 100644
index 4a41ced..000
--- a/drivers/mtd/maps/ixp2000.c
+++ /dev/null
@@ -1,253 +0,0 @@
-/*
- * drivers/mtd/maps/ixp2000.c
- *
- * Mapping for the Intel XScale IXP2000 based systems
- *
- * Copyright (C) 2002 Intel Corp.
- * Copyright (C) 2003-2004 MontaVista Software, Inc.
- *
- * Original Author: Naeem M Afzal naeem.m.af...@intel.com
- * Maintainer: Deepak Saxena dsax...@plexity.net
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include linux/module.h
-#include linux/types.h
-#include linux/init.h
-#include linux/kernel.h
-#include linux/string.h
-#include linux/slab.h
-#include linux/ioport.h
-#include linux/device.h
-#include linux/platform_device.h
-
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-
-#include asm/io.h
-#include mach/hardware.h
-#include asm/mach/flash.h
-
-#include linux/reboot.h
-
-struct ixp2000_flash_info {
- struct mtd_info *mtd;
- struct map_info map;
- struct resource *res;
-};
-
-static inline unsigned long flash_bank_setup(struct map_info *map, unsigned
long ofs)
-{
- unsigned long (*set_bank)(unsigned long) =
- (unsigned long(*)(unsigned long))map-map_priv_2;
-
- return (set_bank ? set_bank(ofs) : ofs);
-}
-
-#ifdef __ARMEB__
-/*
- * Rev A0 and A1 of IXP2400 silicon have a broken addressing unit which
- * causes the lower address bits to be XORed with 0x11 on 8 bit accesses
- * and XORed with 0x10 on 16 bit accesses. See the spec update, erratum 44.
- */
-static int erratum44_workaround = 0;
-
-static inline unsigned long address_fix8_write(unsigned long addr)
-{
- if (erratum44_workaround) {
- return (addr ^ 3);
- }
- return addr;
-}
-#else
-
-#define address_fix8_write(x) (x)
-#endif
-
-static map_word ixp2000_flash_read8(struct map_info *map, unsigned long ofs)
-{
- map_word val;
-
- val.x[0] = *((u8 *)(map-map_priv_1 + flash_bank_setup(map, ofs)));
- return val;
-}
-
-/*
- * We can't use the standard memcpy due to the broken SlowPort
- * address translation on rev A0 and A1 silicon and the fact that
- * we have banked flash.
- */
-static void ixp2000_flash_copy_from(struct map_info *map, void *to,
- unsigned long from, ssize_t len)
-{
- from = flash_bank_setup(map, from);
- while(len--)
- *(__u8 *) to++ = *(__u8 *)(map-map_priv_1 + from++);
-}
-
-static void ixp2000_flash_write8(struct map_info *map, map_word d, unsigned
long ofs)
-{
- *(__u8 *) (address_fix8_write(map-map_priv_1 +
- flash_bank_setup(map, ofs))) = d.x[0];
-}
-
-static void ixp2000_flash_copy_to(struct map_info *map, unsigned long to,
- const void *from, ssize_t len)
-{
- to = flash_bank_setup(map, to);
- while(len
Re: Dead mappings and drivers in MTD
On Mon, 2013-03-11 at 09:20 -0700, Olof Johansson wrote: On Mon, Mar 11, 2013 at 8:34 AM, Artem Bityutskiy dedeki...@gmail.com wrote: Hi MTD folks, we have huge amount of drivers, espacially mapping drives in 'drivers/mtd', and for sure may of them are for ancient devices which are long dead and not supported by modern kernels anyway. I would like to do a small clean-up. It is difficult to judge which ones are dead for me, so I am asking the community to help. Thanks! There are few easy cases - some drivers depend on Kconfig symbols which are not defined anywhere - I guess these are clear candidates for removal. For example this one: config MTD_DBOX2 tristate CFI Flash device mapped on D-Box2 depends on DBOX2 MTD_CFI_INTELSTD MTD_CFI_INTELEXT MTD_CFI_AMDSTD help This enables access routines for the flash chips on the Nokia/Sagem D-Box 2 board. If you have one of these boards and would like to use Grepping for DBOX2 gives nothing. In 2.6.14, it dropped two dependencies that used to be there for PPC32 and 8xx. There still was no DBOX2 symbol to fulfill that dependency back then. Take it out, if someone finds a user later on it can always be reverted. Seems very very unlikely in this case. I agree, thanks. I've quickly went through all the MTD map drivers and found many candidates for removal. I did not prepare a patch-set yet, but the below commit messages from my tree should give enough info about what I am thinking to remove. Author: Artem Bityutskiy artem.bityuts...@linux.intel.com Date: Mon Mar 11 18:24:37 2013 +0200 mtd: remove the mbx860 map driver This driver depends on CONFIG_MBX which is not defined anywhere, which means this driver is dead. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com drivers/mtd/maps/Kconfig |9 -- drivers/mtd/maps/Makefile |1 - drivers/mtd/maps/ixp2000.c | 253 3 files changed, 263 deletions(-) commit 3e8b189c4fad6196333fb2069ab1f183b652a81d Author: Artem Bityutskiy artem.bityuts...@linux.intel.com Date: Mon Mar 11 18:10:06 2013 +0200 mtd: remove the dilnetpc map driver support This driver is marked as broken for very long time. Most probably this board is just something ancient no one cares about anyway. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com drivers/mtd/maps/Kconfig| 16 -- drivers/mtd/maps/Makefile |1 - drivers/mtd/maps/dilnetpc.c | 496 --- 3 files changed, 513 deletions(-) commit e9313043d5bb4b2429b60092ebd9974598b5b62d Author: Artem Bityutskiy artem.bityuts...@linux.intel.com Date: Mon Mar 11 18:07:35 2013 +0200 mtd: remove the tqm8xxl map driver This driver depends on the CONFIG_TQM8xxL symbol, which is not defined anywhere, which means that this driver is dead. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com drivers/mtd/maps/Kconfig | 10 -- drivers/mtd/maps/Makefile |1 - drivers/mtd/maps/tqm8xxl.c | 249 3 files changed, 260 deletions(-) commit 1b17ddb0219d9ab6b96a2bc22331d89ac4ca4539 Author: Artem Bityutskiy artem.bityuts...@linux.intel.com Date: Mon Mar 11 18:05:13 2013 +0200 pcmcia: remove RPX board stuff The RPX board is not supported by the kernel because CONFIG_RPXCLASSIC and CONFIG_RPXLITE symbols and not defined anywhere. Clean-up the m8xx_pcmcia driver a little bit. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com drivers/pcmcia/m8xx_pcmcia.c | 81 -- 1 file changed, 81 deletions(-) commit 518fa5d9718cbe00ed3de3798761cc051dcef04b Author: Artem Bityutskiy artem.bityuts...@linux.intel.com Date: Mon Mar 11 18:03:11 2013 +0200 m68k: remove rpxlite stuff The CONFIG_RPXLITE is not defined anywhere, which means that this board is not supported anyway, and we can clean-up commproc.h a little. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com arch/m68k/include/asm/commproc.h | 17 - 1 file changed, 17 deletions(-) commit de70cc56d0c067275c3cac5659196d9ef4043888 Author: Artem Bityutskiy artem.bityuts...@linux.intel.com Date: Mon Mar 11 18:01:02 2013 +0200 mtd: maps: kill the rpxlite map driver This driver depends on the CONFIG_RPXCLASSIC and CONFIG_RPXLITE symbols, which are not defined anywhere, and this means that this driver is dead. Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com drivers/mtd/maps/Kconfig | 10 --- drivers/mtd/maps/Makefile |1 - drivers/mtd/maps/rpxlite.c | 64 3 files changed, 75 deletions(-) commit 1ebbc11e1e2a143308689af47bb766824c035285 Author: Artem
Re: [PATCH] driver/mtd/IFC:Wait tWB time, poll R/B before command execution
On Thu, 2012-11-08 at 13:42 +0530, Prabhakar Kushwaha wrote: IFC_FIR_OP_CMD0 issues command for execution without checking flash readiness. It may cause problem if flash is not ready. Instead use IFC_FIR_OP_CW0 which Wait for tWB time and poll R/B to return high or time-out, before issuing command. NAND_CMD_READID command implemention does not fulfill above requirement. So update its programming. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com Signed-off-by: Hemant Nautiyal hemant.nauti...@freescale.com Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] driver/mtd:IFC NAND:Initialise internal SRAM before any write
On Thu, 2012-09-13 at 07:53 -0500, Kumar Gala wrote: drivers/mtd/nand/fsl_ifc_nand.c | 56 ++- 1 file changed, 55 insertions(+), 1 deletion(-) If MTD maintainers ack, I'm happy to pull this in via PPC tree. Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
platform_device *op)
retval = mtd_device_parse_register(mtd, NULL, ppdata, NULL, 0);
if (retval) {
dev_err(dev, Error adding MTD device!\n);
- devm_free_irq(dev, prv-irq, mtd);
goto error;
}
return 0;
error:
- mpc5121_nfc_free(dev, mtd);
+ clk_disable(prv-clk);
return retval;
}
@@ -857,8 +833,7 @@ static int __devexit mpc5121_nfc_remove(struct
platform_device *op)
struct mpc5121_nfc_prv *prv = chip-priv;
nand_release(mtd);
- devm_free_irq(dev, prv-irq, mtd);
- mpc5121_nfc_free(dev, mtd);
+ clk_disable(prv-clk);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards,
Artem Bityutskiy
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] drivers/mtd/nand/mpc5121_nfc.c: some devm_ cleanups
On Tue, 2012-09-04 at 11:44 +0200, Julia Lawall wrote: I've been bitten by the same issue recently, also cause by one of these cocci devm patches. devm_clk_get is only available if the generic clk_get/clk_put implementation is used. Not all architectures do this and some implement their own clk_get/clk_put, etc functions. Since devm_clk_get is merely a wrapper around clk_get/clk_put there is no reason why it should depend CLKDEV_LOOKUP. I've prepared a patch which makes them generically available if the clk_get/clk_put are implemented (i.e. if HAVE_CLK is set), but it is on a different machine right now, will try to submit it later today. Sorry about this. I wasn't aware that devm_clk_get wasn't supported by all architectures, and I have no way of compiling code for these architectures... But I wonder why it is not, since devm-ness doesn't seem to have anything to do with architecture-specific details? It would be really nice to have it for all architectures, because the clock functions are just as (or at least almost as) common as kzalloc, ioremap, etc. It looks like Lars is going to fix this. I am personally fine if you send patches without build-testing them. Your patches are generally of good quality and you send many of them, so build-testing each would be too much for you. And at least for MTD, I can build-test myself. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kconfig: remove CONFIG_MTD_NAND_VERIFY_WRITE
On Wed, 2012-08-15 at 17:12 +0800, Huang Shijie wrote: Just as Artem suggested: Both UBI and JFFS2 are able to read verify what they wrote already. There are also MTD tests which do this verification. So I think there is no reason to keep this in the NAND layer, let alone wasting RAM in the driver to support this feature. So kill MTD_NAND_VERIFY_WRITE entirely. Please see the patch: http://lists.infradead.org/pipermail/linux-mtd/2012-August/043189.html This patch removes the CONFIG_MTD_NAND_VERIFY_WRITE in the defconfigs. Signed-off-by: Huang Shijie b32...@freescale.com Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] mtd: delete SBC82xx/SBC8560 MTD mapping support
On Tue, 2012-06-26 at 15:54 -0400, Paul Gortmaker wrote: The SBC8260 support was dropped back when we moved from ppc to powerpc. We are now also dropping the support for the EOL SBC8560, so we can also delete this mapping support, as they were the only users of it. Cc: David Woodhouse david.woodho...@intel.com Cc: linux-...@lists.infradead.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com You forgot this: diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile index 68a9a91..deb43e9 100644 --- a/drivers/mtd/maps/Makefile +++ b/drivers/mtd/maps/Makefile @@ -47,7 +47,6 @@ obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o obj-$(CONFIG_MTD_H720X)+= h720x-flash.o obj-$(CONFIG_MTD_IXP4XX) += ixp4xx.o obj-$(CONFIG_MTD_IXP2000) += ixp2000.o -obj-$(CONFIG_MTD_WRSBC8260)+= wr_sbc82xx_flash.o obj-$(CONFIG_MTD_DMV182) += dmv182.o obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o I've amended the patch and pushed to l2-mtd.git tree, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd: Fix typo in Kconfig
On Thu, 2012-05-17 at 22:43 +0200, Frank Svendsboe wrote: MTD_OF_PARTS and the default setting is not working due to using 'Y' instead of 'y', introduced in commit d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and possibly other boards using DTS defined partitions and not having CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root after v3.1. The commit was released in v3.2, so it not v3.1 probably? Signed-off-by: Frank Svendsboe frank.svends...@gmail.com I've amended the subject to make it look scarier than just a fix of a typo, added a tag for the stable tree, and pushed to l2-mtd.git, thanks! commit aa2465b2d5d44defb269ac66a2d2b6e6b8feb399 Author: Frank Svendsboe frank.svends...@gmail.com Date: Thu May 17 22:43:09 2012 +0200 mtd: of_parts: fix breakage in Kconfig MTD_OF_PARTS and the default setting is not working due to using 'Y' instead of 'y', introduced in commit d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and possibly other boards using DTS defined partitions and not having CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root. Signed-off-by: Frank Svendsboe frank.svends...@gmail.com Cc: sta...@kernel.org [3.2+] Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] driver/mtd: IFC NAND: Add support of ONFI NAND flash
On Mon, 2012-04-09 at 10:55 +0530, Prabhakar Kushwaha wrote: - Fix NAND_CMD_READID command for ONFI detect. - Add NAND_CMD_PARAM command to read the ONFI parameter page. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com Acked-by: Scott Wood scottw...@freescale.com --- Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Branch master Pushed to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command
On Wed, 2012-01-18 at 09:43 +0530, Prabhakar Kushwaha wrote: Freescale IFC NAND Machine calculates ECC on 512byte sector and same is used in fsl_ifc_run_command() during ECC status verification. Also this sector is passed to is_blank() for blank checking. It is wrong at first place because is_blank()'s implementation checks for Page size and OOB area size. is_blank() should be called per page for main and OOB area verification. Variables name are redefined to avoid confusion between buffer and ecc sector. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com The driver is not in 3.3-rc1, so I skip this patch. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
On Tue, 2011-12-20 at 06:40 +, Liu Shengzhou-B36685 wrote: -Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Saturday, December 17, 2011 10:45 PM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; dw...@infradead.org; Gala Kumar-B11780; linux-...@lists.infradead.org Subject: Re: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller On Mon, 2011-12-12 at 17:40 +0800, Shengzhou Liu wrote: There was a bug for fmr initialization, which lead to fmr was always 0x100 in fsl_elbc_chip_init() and caused FCM command timeout before calling fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value and not relying on the setting of bootloader. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Pushed both to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy I noted it had been applied in linux-next.git tree. Does it still need to l2-mtd-2.6.git? Thanks. It is in linux-next because it is pulled there from l2-mtd-2.6.git. Thanks for head up, but no, it should stay in the l2-mtd-2.6.git. David Woodhouse then should take care of merging the l2 tree upstream. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, 2011-12-12 at 15:30 -0600, Scott Wood wrote: On 12/12/2011 03:19 PM, Artem Bityutskiy wrote: On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote: NAND chips come from the factory with bad blocks marked at a certain offset into each page. This offset is normally in the OOB area, but since we change the layout from 4k data, 128 byte oob to 2k data, 64 byte oob, 2k data, 64 byte oob the marker is no longer in the oob. On first use we need to migrate the markers so that they are still in the oob. Ah, I see, thanks. Are you planning to implement in-kernel migration or use a user-space tool? That's the kind of answer I was hoping to get from Shuo. :-) Most likely is a firmware-based tool, but I'd like there to be some way for the tool to mark that this has happened, so that the Linux driver can refuse to do non-raw accesses to a chip that isn't marked as having been migrated (or at least yell loudly in the log). Speaking of raw accesses, these are currently broken in the eLBC driver... we need some way for the generic layer to tell us what kind of access it is before the transaction starts, not once it wants to read out the buffer (unless we add more hacks to delay the start of a read transaction until first buffer access...). We'd be better off with a high-level read page/write page function that does the whole thing (not just buffer access, but command issuance as well). It looks like currently you can re-define chip-read_page, so I guess you should rework MTD and make chip-write_page re-definable? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand: fixup for fmr initialization of Freescale NAND controller
On Mon, 2011-12-12 at 17:40 +0800, Shengzhou Liu wrote: There was a bug for fmr initialization, which lead to fmr was always 0x100 in fsl_elbc_chip_init() and caused FCM command timeout before calling fsl_elbc_chip_init_tail(), now we initialize CWTO to maximum timeout value and not relying on the setting of bootloader. Signed-off-by: Shengzhou Liu shengzhou@freescale.com Pushed both to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] Integrated Flash Controller support
On Wed, 2011-12-14 at 11:13 +, Li Yang-R58472 wrote: -Original Message- From: Artem Bityutskiy [mailto:dedeki...@gmail.com] Sent: Wednesday, November 30, 2011 4:51 PM To: Kumar Gala Cc: Wood Scott-B07421; Li Yang-R58472; Liu Shuo-B35362; linux- ker...@vger.kernel.org Kernel; linux-...@lists.infradead.org; Andrew Morton; David Woodhouse; linuxppc-dev@lists.ozlabs.org list Subject: Re: [PATCH v2] Integrated Flash Controller support On Tue, 2011-11-29 at 19:47 -0600, Kumar Gala wrote: As Scott said, I was more asking about the 2nd patch in the sequence which did touch MTD. Since that one is dependent on this patch, wondering how we wanted to handle them. I do not have time to review it, but it looks OK, so I'd suggest to merge it vie the same tree as the rest of the patches. Hi Artem, So what is your suggestion on this patch? Can we regard your previous email as an ACK and merge it through the powerpc tree? Or do you prefer to merge them through the MTD tree with Kumar's ACK instead? I am fine if it is merged via PPC tree. I do not have bandwith to look at it closely, so I cannot ack it, although I also do not have reasons to nack it :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
On Fri, 2011-12-09 at 17:42 +0800, shuo@freescale.com wrote: From: Liu Shuo b35...@freescale.com If we use the Nand flash chip whose number of pages in a block is greater than 64(for large page), we must treat the low bit of FBAR as being the high bit of the page address due to the limitation of FCM, it simply uses the low 6-bits (for large page) of the combined block/page address as the FPAR component, rather than considering the actual block size. Pushed this one to l2-mtd-2.6.git, thanks! Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, 2011-12-06 at 18:09 -0600, Scott Wood wrote: On 12/03/2011 10:31 PM, shuo@freescale.com wrote: From: Liu Shuo shuo@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save them to a large buffer. Signed-off-by: Liu Shuo shuo@freescale.com --- v3: -remove page_size of struct fsl_elbc_mtd. -do a oob write by NAND_CMD_RNDIN. drivers/mtd/nand/fsl_elbc_nand.c | 243 ++ 1 files changed, 218 insertions(+), 25 deletions(-) What is the plan for bad block marker migration? Why it should be migrated? I thought that you support 2KiB pages, and this adds 4 and 8 KiB pages support, which you never supported before. What is the migration you guys are talking about? Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote: NAND chips come from the factory with bad blocks marked at a certain offset into each page. This offset is normally in the OOB area, but since we change the layout from 4k data, 128 byte oob to 2k data, 64 byte oob, 2k data, 64 byte oob the marker is no longer in the oob. On first use we need to migrate the markers so that they are still in the oob. Ah, I see, thanks. Are you planning to implement in-kernel migration or use a user-space tool? Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote: From: Liu Shuo shuo@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save them to a large buffer. Signed-off-by: Liu Shuo shuo@freescale.com This patch does not apply on top of my l2-mtd-2.6.git tree. Could you please send a patch that applies cleanly? Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, 2011-12-05 at 13:46 -0600, Scott Wood wrote: Because this is a controller resource, shared by multiple NAND chips that may be different page sizes (even if not, it's adding another point of synchronization required between initialization of different chips). I don't think it's worth the gymnastics to save a few KiB. OK, I see. Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote:
+ /*
+ * Freescale FCM controller has a 2K size limitation of buffer
+ * RAM, so elbc_fcm_ctrl-buffer have to be used if writesize
+ * of chip is greater than 2048.
+ * We malloc a large enough buffer (maximum page size is 16K).
+ */
+ elbc_fcm_ctrl-buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL);
+ if (!elbc_fcm_ctrl-buffer) {
+ dev_err(dev, failed to allocate memory\n);
+ mutex_unlock(fsl_elbc_nand_mutex);
+ ret = -ENOMEM;
+ goto err;
+ }
Sorry for returning to this again and agian - I do not have time to dig
suggest you the right solutions on the one hand, you do not provide me a
good answer on the other hand (or I forgot?).
16KiB pages do not even exist I believe. And you kmalloc 33KiB or RAM
although in most cases you need only 5KiB. I think this is wrong - what
is the very strong reason of wasting RAM you have?
Why you cannot allocate exactly the required amount of RAM after
'nand_scan_ident()' finishes and you know the page size?
Artem.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl-oob to set FPAR_MS bit of FPAR
On Sun, 2011-12-04 at 12:31 +0800, shuo@freescale.com wrote: From: Liu Shuo b35...@freescale.com On both of large-page chip and small-page chip, we always should use 'elbc_fcm_ctrl-oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't use a overflowed 'column' to set it. Signed-off-by: Liu Shuo b35...@freescale.com Signed-off-by: Li Yang le...@freescale.com Pushed patches 1 and 2 to l2-mtd-2.6.git, thanks! Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] Integrated Flash Controller support
On Tue, 2011-11-29 at 19:47 -0600, Kumar Gala wrote: As Scott said, I was more asking about the 2nd patch in the sequence which did touch MTD. Since that one is dependent on this patch, wondering how we wanted to handle them. I do not have time to review it, but it looks OK, so I'd suggest to merge it vie the same tree as the rest of the patches. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] Integrated Flash Controller support
On Mon, 2011-10-31 at 17:38 +0800, b35...@freescale.com wrote:
+/*
+ * fsl_ifc_ctrl_probe
+ *
+ * called by device layer when it finds a device matching
+ * one our driver can handled. This code allocates all of
+ * the resources needed for the controller only. The
+ * resources for the NAND banks themselves are allocated
+ * in the chip probe function.
+*/
+static int __devinit fsl_ifc_ctrl_probe(struct platform_device *dev)
+{
+ int ret = 0;
+
+
... snip ...
I am concerned about the error path in this function
+ init_waitqueue_head(fsl_ifc_ctrl_dev-nand_wait);
+
+ ret = request_irq(fsl_ifc_ctrl_dev-irq, fsl_ifc_ctrl_irq, IRQF_SHARED,
+ fsl-ifc, fsl_ifc_ctrl_dev);
+ if (ret != 0) {
+ dev_err(dev-dev, failed to install irq (%d)\n,
+ fsl_ifc_ctrl_dev-irq);
+ goto err;
+ }
irq_dispose_mapping() on error path?
+
+ ret = request_irq(fsl_ifc_ctrl_dev-nand_irq, fsl_ifc_nand_irq, 0,
+ fsl-ifc-nand, fsl_ifc_ctrl_dev);
+ if (ret != 0) {
+ dev_err(dev-dev, failed to install irq (%d)\n,
+ fsl_ifc_ctrl_dev-nand_irq);
+ goto err;
free_irq() on error path?
+ }
+
+ return 0;
+
+err:
+ return ret;
+}
+static __init int fsl_ifc_init(void)
+{
+ int ret;
+
+ ret = platform_driver_register(fsl_ifc_ctrl_driver);
+ if (ret)
+ printk(KERN_ERR fsl-ifc: Failed to register platform
+ driver\n);
+
+ return ret;
+}
+
+static void __exit fsl_ifc_exit(void)
+{
+ platform_driver_unregister(fsl_ifc_ctrl_driver);
+}
+
+module_init(fsl_ifc_init);
+module_exit(fsl_ifc_exit);
How about using module_platform_driver() instead?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] Integrated Flash Controller support
On Thu, 2011-11-24 at 08:24 -0600, Kumar Gala wrote: On Nov 22, 2011, at 9:41 PM, Kumar Gala wrote: On Oct 31, 2011, at 4:38 AM, b35...@freescale.com b35...@freescale.com wrote: From: Liu Shuo b35...@freescale.com Integrated Flash Controller supports various flashes like NOR, NAND and other devices using NOR, NAND and GPCM Machine available on it. IFC supports four chip selects. Signed-off-by: Dipen Dudhat dipen.dud...@freescale.com Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: Li Yang le...@freescale.com Signed-off-by: Liu Shuo b35...@freescale.com --- arch/powerpc/Kconfig |4 + arch/powerpc/include/asm/fsl_ifc.h | 834 arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/fsl_ifc.c | 322 ++ 4 files changed, 1161 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/include/asm/fsl_ifc.h create mode 100644 arch/powerpc/sysdev/fsl_ifc.c Guys, How are we handling this patchset since it touches drivers/mtd/nand? I do not see it touching MTD from the diffstat above. I am a little bit confused why a flash controller is added to arch/powerpc/sysdev/fsl_ifc.c ? Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Thu, 2011-11-24 at 07:49 +, Li Yang-R58472 wrote: Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip On Thu, 2011-11-24 at 08:41 +0800, b35...@freescale.com wrote: + /* +* Freescale FCM controller has a 2K size limitation of buffer +* RAM, so elbc_fcm_ctrl-buffer have to be used if writesize +* of chip is greater than 2048. +* We malloc a large enough buffer (maximum page size is 16K). +*/ + elbc_fcm_ctrl-buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL); Are there NANDs with 16KiB page size? We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size? I do not know, but I know that allocating 32KiB of contiguous physical RAM may cause unneeded memory pressure and even fail if the memory is too fragmented. So I would not go for this unless this is necessary. Did you try to look how the NAND base interface could be changed to avoid re-allocation altogether, BTW? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Thu, 2011-11-24 at 18:02 +0800, LiuShuo wrote: 于 2011年11月24日 16:16, Artem Bityutskiy 写道: On Thu, 2011-11-24 at 07:49 +, Li Yang-R58472 wrote: Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip On Thu, 2011-11-24 at 08:41 +0800, b35...@freescale.com wrote: + /* +* Freescale FCM controller has a 2K size limitation of buffer +* RAM, so elbc_fcm_ctrl-buffer have to be used if writesize +* of chip is greater than 2048. +* We malloc a large enough buffer (maximum page size is 16K). +*/ + elbc_fcm_ctrl-buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL); Are there NANDs with 16KiB page size? We are not sure, but are there possibility that chip with 16K page will appear? Or maybe we can add a MACRO for the maximum page size? I do not know, but I know that allocating 32KiB of contiguous physical RAM may cause unneeded memory pressure and even fail if the memory is too fragmented. So I would not go for this unless this is necessary. What is your suggestion ? 8k is enough ? Up to you, I do not have suggestions, just expressed a concern. I'd keep the buffer smaller if possible. By the time 16KiB pages appear, your HW may retire already :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Thu, 2011-11-24 at 08:41 +0800, b35...@freescale.com wrote: + /* +* Freescale FCM controller has a 2K size limitation of buffer +* RAM, so elbc_fcm_ctrl-buffer have to be used if writesize +* of chip is greater than 2048. +* We malloc a large enough buffer (maximum page size is 16K). +*/ + elbc_fcm_ctrl-buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL); Are there NANDs with 16KiB page size? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote: + /* +* Freescale FCM controller has a 2K size limitation of buffer +* RAM, so elbc_fcm_ctrl-buffer have to be used if writesize +* of chip is greater than 2048. +* We malloc a large enough buffer at this point, because we +* don't know writesize before calling nand_scan(). We will +* re-malloc later if needed. +*/ + elbc_fcm_ctrl-buffer = kmalloc(4096 * 6, GFP_KERNEL); + if (!elbc_fcm_ctrl-buffer) + return -ENOMEM; Why 4096*6? Judging from the comment it should be 4096. Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
On Fri, 2011-11-18 at 10:08 +0800, LiuShuo wrote: Ok and I want to add another patch before 3/3. -LiuShuo On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote: From: Liu Shuob35...@freescale.com If we use the Nand flash chip whose number of pages in a block is greater than 64(for large page), we must treat the low bit of FBAR as being the high bit of the page address due to the limitation of FCM, it simply uses the low 6-bits (for large page) of the combined block/page address as the FPAR component, rather than considering the actual block size. Looks like this patch depends on the previous white-space clean-up patch - could you please refactor it (and 3/3 too) and resend? Ok and I am going to add another new patch before 3/3. Sure, send 3/3 as well because this one depends on the cleanup patch, so cannot be applied independently. Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mtd/nand: fix coding style issue in drivers/mtd/nand/fsl_elbc.c
On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote: From: Liu Shuo b35...@freescale.com fix whitespaces,tabs coding style issue and use #include linux/io.h instead of asm/io.h in drivers/mtd/nand/fsl_elbc.c. Signed-off-by: Liu Shuo b35...@freescale.com Signed-off-by: Li Yang le...@freescale.com Hi, It is really matter of taste whether to use only tabs for indentations or tabs + few spaces to align nicely with the previous line. I personally prefer the latter and dislike when people use only tabs. But other people love tabs and use them everywhere, even like #define\tBLAH_BLAH\tvalue, which I find ugly, but I do not mind people using this. So no, please, let's leave the indentation as is in this file. It is ok to assume tab is 8 spaces in the kernel. Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] mtd/nand : set Nand flash page address to FBAR and FPAR correctly
On Tue, 2011-11-15 at 17:29 +0800, b35...@freescale.com wrote: From: Liu Shuo b35...@freescale.com If we use the Nand flash chip whose number of pages in a block is greater than 64(for large page), we must treat the low bit of FBAR as being the high bit of the page address due to the limitation of FCM, it simply uses the low 6-bits (for large page) of the combined block/page address as the FPAR component, rather than considering the actual block size. Looks like this patch depends on the previous white-space clean-up patch - could you please refactor it (and 3/3 too) and resend? Artem. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd: m25p80: add EON flash EN25Q32B into spi flash id table
On Fri, 2011-09-30 at 15:08 +0800, Shaohui Xie wrote: Add support for EON spi flash EN25Q32B, which is not listed in id table, need to add it in the id table to support the EON flash. Signed-off-by: Shaohui Xie shaohui@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Pushed to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, 2011-08-22 at 10:58 -0500, Scott Wood wrote: On 08/22/2011 05:58 AM, Artem Bityutskiy wrote: On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote: On 08/19/2011 03:57 AM, Matthieu CASTET wrote: How the bad block marker are handled with this remapping ? It has to be migrated prior to first use (this needs to be documented, and ideally a U-Boot command provided do do this), or else special handling would be needed when building the BBT. The only way around this would be to do ECC in software, and do the buffering needed to let MTD treat it as a 4K chip. It really feels like a special hack which would better not go to mainline - am I the only one with such feeling? If yes, probably I am wrong... While the implementation is (of necessity) a hack, the feature is something that multiple people have been asking for (it's not a special case for a specific user). They say 2K chips are getting more difficult to obtain. It doesn't change anything for people using 512/2K chips, and (in its current form) doesn't introduce significant complexity to the driver. I'm not sure how maintaining it out of tree would be a better situation for anyone. I am just afraid that (a) other drivers will do this (b) this will start causing various weird bug-reports... -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, 2011-08-23 at 11:12 -0500, Scott Wood wrote: On 08/23/2011 05:02 AM, Matthieu CASTET wrote: LiuShuo a écrit : We can't read the NOP from the ID on any chip. Some chips don't give this infomation.(e.g. Micron MT29F4G08BAC) Are there any 4K+ chips (especially ones with insufficient NOP) that don't have the info? This chip is 2K and NOP8. Is there an easy way (without needing to have every datasheet for every chip ever made) to determine at runtime which chips supply this information? Doesn't the micron chip provide it with onfi info ? This chip doesn't appear to be ONFI. Few quick thoughts. 1. I think that if driver is able to detect flash NOP parameter and refuse flashes with too low NOP, then your change is OK. 2. For ONFI flashes, can we take NOP from ONFI info? 3. For non-ONFI chip, is it fair to conclude that MLCs _all_ have NOP 1? Can distinguish between MLC/SLC? If not, can this table help: http://www.linux-mtd.infradead.org/nand-data/nanddata.html? If needed, can we put bits-per-cell data to 'struct nand_flash_dev nand_flash_ids' ? 4. Can we add a NOP field to 'struct nand_flash_dev nand_flash_ids' array? -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Thu, 2011-08-18 at 10:33 +0800, b35...@freescale.com wrote: From: Liu Shuo b35...@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we divide a page into multi-2K pages for MTD layer driver. In that case, we force to set the page size to 2K bytes. We convert the page address of MTD layer driver to a real page address in flash chips and a column index in fsl_elbc driver. We can issue any column address by UA instruction of elbc controller. NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in the Same Page (NOP)', the flash chip which is supported by this workaround have to meet below conditions. 1. page size is not greater than 4KB 2. 1) if main area and spare area have independent NOPs: main area NOP:=3 spare area NOP:=2 2) if main area and spare area have a common NOP: NOP :=4 Could you please also add this kind of info to the driver code comments? Does it also make sense to print a message if you do the emulation, like: pr_info(attention! emulating 2KiB NAND pages!); -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote: On 08/19/2011 03:57 AM, Matthieu CASTET wrote: LiuShuo a écrit : 于 2011年08月19日 01:00, Matthieu CASTET 写道: b35...@freescale.com a écrit : From: Liu Shuob35...@freescale.com Freescale FCM controller has a 2K size limitation of buffer RAM. In order to support the Nand flash chip whose page size is larger than 2K bytes, we divide a page into multi-2K pages for MTD layer driver. In that case, we force to set the page size to 2K bytes. We convert the page address of MTD layer driver to a real page address in flash chips and a column index in fsl_elbc driver. We can issue any column address by UA instruction of elbc controller. Why do you need to do that ? When mtd send you a 4k page, why can't you write it by 2*2k pages write ? 1. It's easy to implement. 2. We don't need to move the data in buffer more times, because we want to use the HW_ECC. In flash chip per Page: | first data | first oob | second data | second oob | How the bad block marker are handled with this remapping ? It has to be migrated prior to first use (this needs to be documented, and ideally a U-Boot command provided do do this), or else special handling would be needed when building the BBT. The only way around this would be to do ECC in software, and do the buffering needed to let MTD treat it as a 4K chip. It really feels like a special hack which would better not go to mainline - am I the only one with such feeling? If yes, probably I am wrong... -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command
On Wed, 2011-08-17 at 15:35 +0800, LiuShuo wrote:
I think We can add a new ioctl MEMSETOOBMODE for selecting a mode to
access the OOB area.
Add new member into struct mtd_info:
struct mtd_info {
..
enum {
MTD_OOB_PLACE,
MTD_OOB_AUTO,
MTD_OOB_RAW,
} oob_mode;
}
In function mtd_do_writeoob() (in drivers/mtd/mtdchar.c) :
- ops.mode = MTD_OOB_PLACE;
+ ops.mode = mtd-oob_mode;
Could we do it like this ?
I think the OOB mode should not be a global MTD device state. Each
ioctl invocation should just specify the mode.
Brian's idea of having a completely new ioctl or a set of new ioctls for
OOB which would copletely deprecate the old ones is a good idea. Let's
wait for his patch.
May be we should even start physically removing depricated ioctls by
first adding a printk with a warning and then removing completely. But
first mtdutils should be updated to not use them.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd-utils: fix corrupt cleanmarker with flash_erase -j command
On Wed, 2011-08-03 at 13:50 +0800, b35...@freescale.com wrote:
From: Liu Shuo b35...@freescale.com
Flash_erase -j should fill discrete freeoob areas with required bytes
of JFFS2 cleanmarker in jffs2_check_nand_cleanmarker(). Not just fill
the first freeoob area.
Signed-off-by: Liu Shuo b35...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
...
/*
* Process user arguments
@@ -197,15 +198,40 @@ int main(int argc, char *argv[])
if (ioctl(fd, MEMGETOOBSEL, oobinfo) != 0)
return sys_errmsg(%s: unable to get NAND
oobinfo, mtd_device);
+ cleanmarker.totlen = cpu_to_je32(8);
/* Check for autoplacement */
if (oobinfo.useecc == MTD_NANDECC_AUTOPLACE) {
+ struct nand_ecclayout_user ecclayout;
/* Get the position of the free bytes */
- if (!oobinfo.oobfree[0][1])
+ if (ioctl(fd, ECCGETLAYOUT, ecclayout) != 0)
+ return sys_errmsg(%s: unable to get
NAND ecclayout, mtd_device);
+
Hmm, shouldn't we instead make MTD_OOB_AUTO be available for userspace
via an ioctl instead and make flash_eraseall use it instead?
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd: eLBC NAND: update ecc_stats.corrected when lteccr available
On Tue, 2011-07-26 at 15:07 -0500, Michael Hench wrote: update ecc_stats.corrected if LTECCR register is available. v2: kernel standard C formatting v3: kernel standard C formatting again, changed a comment to get under 80 chars Signed-off-by: Michael Hench michaelhe...@gmail.com Pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, 2011-07-12 at 12:48 +0800, b35...@freescale.com wrote:
+ /*
+ * Hack for supporting the flash chip whose writesize is
+ * larger than 2K bytes.
+ */
+ if (mtd-writesize 2048) {
+ elbc_fcm_ctrl-subpage_shift = ffs(mtd-writesize 11) - 1;
+ elbc_fcm_ctrl-subpage_mask =
+ (1 elbc_fcm_ctrl-subpage_shift) - 1;
+ /*
+ * Rewrite mtd-writesize, mtd-oobsize, chip-page_shift
+ * and chip-pagemask.
+ */
+ mtd-writesize = 2048;
+ mtd-oobsize = 64;
+ chip-page_shift = ffs(mtd-writesize) - 1;
+ chip-pagemask = (chip-chipsize chip-page_shift) - 1;
+ }
So basically if the flash has 4KiB NAND pages, you are considering it as
a flash with 2KiB NAND pages. But surely this will work only if the
underlying flash has NOP 2 at least. Or even, if you consider that JFFS2
and YAFFS want to write to OOB, you need NOP 4 (2 ECC writes and 2
writes from YAFFS/JFFS2) ? So this won't work for NOP1 flashes? Isn't it
an ugly hack?
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, 2011-08-15 at 11:11 -0500, Scott Wood wrote:
On 08/15/2011 10:59 AM, Artem Bityutskiy wrote:
On Tue, 2011-07-12 at 12:48 +0800, b35...@freescale.com wrote:
+ /*
+ * Hack for supporting the flash chip whose writesize is
+ * larger than 2K bytes.
+ */
+ if (mtd-writesize 2048) {
+ elbc_fcm_ctrl-subpage_shift = ffs(mtd-writesize 11) - 1;
+ elbc_fcm_ctrl-subpage_mask =
+ (1 elbc_fcm_ctrl-subpage_shift) - 1;
+ /*
+ * Rewrite mtd-writesize, mtd-oobsize, chip-page_shift
+ * and chip-pagemask.
+ */
+ mtd-writesize = 2048;
+ mtd-oobsize = 64;
+ chip-page_shift = ffs(mtd-writesize) - 1;
+ chip-pagemask = (chip-chipsize chip-page_shift) - 1;
+ }
So basically if the flash has 4KiB NAND pages, you are considering it as
a flash with 2KiB NAND pages. But surely this will work only if the
underlying flash has NOP 2 at least. Or even, if you consider that JFFS2
and YAFFS want to write to OOB, you need NOP 4 (2 ECC writes and 2
writes from YAFFS/JFFS2) ? So this won't work for NOP1 flashes?
Right. The set of chips that work with this controller is still larger
with this than without this.
It looks like NOP1 tends to be MLC -- you probably wouldn't want to use
MLC with this controller anyway as it only does 1-bit ECC.
Isn't it an ugly hack?
Less ugly than some other approaches that were considered. :-)
But yes, it's a hack (even says so in the comment). The other option is
it doesn't work.
Could there be at least a fat comment that NANDs with 4KiB pages have to
be at least NOP4? And probably NANDs with 8KiB pages and larger should
simply be rejected?
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev-nand in fsl_elbc_chip_remove()
On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote: From: Liu Shuo b35...@freescale.com The global data fsl_lbc_ctrl_dev-nand don't have to be freed in fsl_elbc_chip_remove(). The right place to do that is in fsl_elbc_nand_remove() if elbc_fcm_ctrl-counter is zero. Signed-off-by: Liu Shuo b35...@freescale.com Changed the subject to something shorted and pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd: eLBC NAND: remove elbc_fcm_ctrl-oob_poi
On Tue, 2011-07-05 at 19:14 -0400, Matthew L. Creech wrote: From: Mike Hench mhe...@elutions.com The eLBC NAND driver currently follows up each program/write operation with a read-back of the page, in order to [ostensibly] fill in ECC data for the caller. However, the page address used for this read is always -1, so the read will never work correctly. Remove this useless (and potentially problematic) block of code. Pushed to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Wed, 2011-06-29 at 11:43 -0500, Scott Wood wrote: On Wed, 29 Jun 2011 09:22:04 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote: + /* Hack for supporting the flash chip whose writesize is + * larger than 2K bytes. + */ Please, use proper kernel multi-line comments. Please, make sure checkpatch.pl does not generate 13 errors with this patch. Most of the checkpatch complaints are about existing style in the file -- particularly, the use of tabs only for indentation, with spaces used for alignment beyond the indentation point. OK, fair enough, but the multi-line comment is a valid complain, although minor. And you guys could just fix the style issues as well in a separate patch-set. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev-nand in fsl_elbc_chip_remove()
On Wed, 2011-06-29 at 11:45 -0500, Scott Wood wrote:
On Wed, 29 Jun 2011 09:20:25 +0300
Artem Bityutskiy dedeki...@gmail.com wrote:
On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote:
From: Liu Shuo b35...@freescale.com
The global data fsl_lbc_ctrl_dev-nand don't have to be freed in
fsl_elbc_chip_remove(). The right place to do that is in
fsl_elbc_nand_remove()
if elbc_fcm_ctrl-counter is zero.
Signed-off-by: Liu Shuo b35...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
b/drivers/mtd/nand/fsl_elbc_nand.c
index 0bb254c..a212116 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -829,7 +829,6 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd
*priv)
elbc_fcm_ctrl-chips[priv-bank] = NULL;
kfree(priv);
- kfree(elbc_fcm_ctrl);
return 0;
}
Do we have to assign fsl_lbc_ctrl_dev-nand to NULL in
fsl_elbc_nand_remove() then? I think that assignment can be killed then.
if (!elbc_fcm_ctrl-counter) {
fsl_lbc_ctrl_dev-nand = NULL;
kfree(elbc_fcm_ctrl);
}
If we're freeing fsl_lbc_ctrl, we'd better get rid of references to it...
Yes, on the one hand this is a good defensive programming practice, on
the other hand it hides double-free bugs. Like this patch fixes a
double-free bug, and why it was noticed before? I thought may be because
of this NULL assignment?
I do not insist though, that was just a suggestion/question.
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev-nand in fsl_elbc_chip_remove()
On Thu, 2011-06-30 at 11:26 -0500, Scott Wood wrote: If the NULL assignment is dropped, consider what happens if the fsl_elbc_nand module is removed then reinserted. On reinsertion, it will see a non-NULL fsl_lbc_ctrl_dev-nand, and will skip allocating a new one. Then you're referencing freed memory. Oh, then this sounds like a separate bug. Removing the module should kill everything, and re-inserging the module should have zero dependencies on the previous states... Anyway, if you think the original patch is OK, I can put it to my tree. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev-nand in fsl_elbc_chip_remove()
On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote:
From: Liu Shuo b35...@freescale.com
The global data fsl_lbc_ctrl_dev-nand don't have to be freed in
fsl_elbc_chip_remove(). The right place to do that is in
fsl_elbc_nand_remove()
if elbc_fcm_ctrl-counter is zero.
Signed-off-by: Liu Shuo b35...@freescale.com
---
drivers/mtd/nand/fsl_elbc_nand.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
b/drivers/mtd/nand/fsl_elbc_nand.c
index 0bb254c..a212116 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -829,7 +829,6 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
elbc_fcm_ctrl-chips[priv-bank] = NULL;
kfree(priv);
- kfree(elbc_fcm_ctrl);
return 0;
}
Do we have to assign fsl_lbc_ctrl_dev-nand to NULL in
fsl_elbc_nand_remove() then? I think that assignment can be killed then.
if (!elbc_fcm_ctrl-counter) {
fsl_lbc_ctrl_dev-nand = NULL;
kfree(elbc_fcm_ctrl);
}
--
Best Regards,
Artem Bityutskiy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, 2011-06-28 at 09:50 +0800, b35...@freescale.com wrote: + /* Hack for supporting the flash chip whose writesize is + * larger than 2K bytes. + */ Please, use proper kernel multi-line comments. Please, make sure checkpatch.pl does not generate 13 errors with this patch. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: NAND BBT corruption on MPC83xx
On Mon, 2011-06-20 at 07:22 -0400, Atlant Schmidt wrote: As far as I know (and I'm sure the list will correct me if I'm wrong! ;-) ), neither UBI nor UBIFS nor any Linux layer provides this routine scrubbing; you have to code it up yourself, probably by accessing the device at the UBI (underlying block device/LEB) layer. UBI will scrub all LEBs with bit-flips once they are read. But if you have bit-flips in an LEB and it is never read, it will never be scrubbed. And erasures of the neighboring PEBs may turn bit-flips into hard errors. To force scrubbing, the easies way is to just read all volumes, like dd if=/dev/ubi0_i of=/dev/null bs=4096 for each i. -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: fix NAND_CMD_READID read bytes number
On Mon, 2011-06-13 at 10:23 +0800, Shaohui Xie wrote: when nand_get_flash_type() is called, it will read 8 bytes of ID instead of 5, but the driver only read 5 bytes, so kernel will dump error messages like: fsl-lbc ffe124000.localbus: read_byte beyond end of buffer fsl-lbc ffe124000.localbus: read_byte beyond end of buffer fsl-lbc ffe124000.localbus: read_byte beyond end of buffer Thanks! -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][upstream] NAND Machine support for Integrated Flash Controller
Hi,
On Wed, 2011-05-25 at 09:30 +0530, Dipen Dudhat wrote:
+ ret = nand_scan_tail(priv-mtd);
+ if (ret)
+ goto err;
+
+#ifdef CONFIG_MTD_PARTITIONS
We've just removed this macro, it should be merged upstream soon, but it
is in the mtd tree so far.
+ /* First look for RedBoot table or partitions on the command
+ * line, these take precedence over device tree information */
+ ret = parse_mtd_partitions(priv-mtd, part_probe_types, parts, 0);
+ if (ret 0)
+ goto err;
+
+#ifdef CONFIG_MTD_OF_PARTS
+ if (ret == 0) {
+ ret = of_mtd_parse_partitions(priv-dev, node, parts);
+ if (ret 0)
+ goto err;
+ }
+#endif
You should invent something to make sure you do not need #ifdef
CONFIG_MTD_OF_PARTS.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Add multiple chip select support to NDFC driver
On Tue, 2011-04-26 at 12:36 +0300, Felix Radensky wrote: This patch extends NDFC driver to support all 4 chip selects available in NDFC NAND controller. Tested on custom 460EX board with 2 chip select NAND device. Signed-off-by: Felix Radensky fe...@embedded-sol.com --- I'd appreciate some testing on 44x boards with multiple NAND devices, like bamboo or DU440, as I don't have access to these boards. drivers/mtd/nand/ndfc.c | 52 +++--- 1 files changed, 35 insertions(+), 17 deletions(-) Pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On Wed, 2011-04-06 at 11:07 +0200, Michal Marek wrote: So additionally, I'd suggest: 1. Instrument checkpatch.pl and make it err or warn on timestamps. This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198 Yeah, great, did not notice, thanks! 2. Probably instrument linux-next to rise a warning when people break this. I'm not sure if Stephen has that much spare time, and I don't think it is necessary. I think the checkpatch check is sufficient and I'll check myself occasionally. Yes, that's fine, I just wanted to speak this out - there is a probability that someone gets excited and creates some instrumentation to kbuild to automatically detect bad things and then Stephen could easily use that. WRT not necessary - well, I think it is always better to cut bad things before they are merged, rather than afterwards. But anyway, let's forget about this. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: Hi, this series makes it possible to build bit-identical kernel image and modules from identical sources. Of course the build is already deterministic in terms of behavior of the code, but the various timestamps embedded in the object files make it hard to compare two builds, for instance to verify that a makefile cleanup didn't accidentally change something. A prime example is /proc/config.gz, which has both a timestamp in the gzip header and a timestamp in the payload data. With this series applied, a script like this will produce identical kernels each time: Very nice stuff. Do you want to take the individual patches through one of your trees, or do you mind if the subsystem maintainers take them through theirs? But unfortunately, it is very easy to break this and for sure it'll be broken very soon. So additionally, I'd suggest: 1. Instrument checkpatch.pl and make it err or warn on timestamps. 2. Probably instrument linux-next to rise a warning when people break this. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Hmm, strange, include linux/vmalloc.h should be enough to use __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll try to look better. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 21:15 +1100, Benjamin Herrenschmidt wrote: On Wed, 2011-03-16 at 09:22 +0200, Artem Bityutskiy wrote: On Wed, 2011-03-16 at 17:50 +1100, ext Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Hmm, strange, include linux/vmalloc.h should be enough to use __vmalloc with 'PAGE_KERNEL' AFAICS, and we have this include... I'll try to look better. Try adding asm/pgtable.h Thanks, that's what I was thinking about as well. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (ubi tree related)
On Wed, 2011-03-16 at 17:50 +1100, Stephen Rothwell wrote: After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_write': drivers/mtd/ubi/io.c:1348: error: 'PAGE_KERNEL' undeclared (first use in this function) drivers/mtd/ubi/io.c: In function 'ubi_dbg_check_all_ff': drivers/mtd/ubi/io.c:1412: error: 'PAGE_KERNEL' undeclared (first use in this function) Caused by commit 823ed5091113 (UBI: allocate write checking buffer on demand). I don't know how to fix this, so I have left it for today. Fixed, sorry for the hassle and thank you! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] Fixing the garbage collector problem after NAND-flash image record in u-boot
On Tue, 2010-11-23 at 18:38 +0100, sergej.stepa...@ids.de wrote: This patch should fix the following problem: 1. the jffs2-image update in the u-boot was ok 2. first restart and first mount of the NAND-flash-partition was also ok 3. before the restart of controller there are no any activity on NAND-flash except of the jffs2_gcd_mtdX-process ... 4. BUT after the second restart the NAND-flash-partition could not be really used after the second mount, dmesg filled with messages: ... jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03ce: 0xc0ff instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x03d0: 0xc0ff instead Just for for info: the behaviour observed on mpc8313-based board with the large-page NAND. The only activity on NAND-flash was the garbage collector process, that looks for CLEANMARKER-nodes As Scott said it was broken by commit 3ab8f2a2e7011c5e83363b42950757e46ef06824 Signed-off-by: Sergej Stepanov sergej.stepa...@ids.de Cc: Rolf Riehle rolf.rie...@ids.de Cc: Scott Wood scottw...@freescale.com Cc: David Woodhouse dw...@infradead.org Pusehd to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 5/5] mtd: m25p80: add support to parse the partitions by OF node
On Sat, 2010-10-16 at 19:05 -0600, Grant Likely wrote: On Sat, Oct 16, 2010 at 1:17 PM, Artem Bityutskiy dedeki...@gmail.com wrote: On Tue, 2010-10-12 at 18:18 +0800, Mingkai Hu wrote: Signed-off-by: Mingkai Hu mingkai...@freescale.com Acked-by: Grant Likely grant.lik...@secretlab.ca --- v4: - Updated to latest kernel base(Linux 2.6.36-rc7). - Made changes according to Grant's comments. Looks good to me, pushed to l2-mtd-2.6.git, thanks. Wait! It will break whenever CONFIG_OF is not set. I broke linux-next with this patch. It can be solved by wrapping the block with #ifdef CONFIG_OF, but I'd like to find a better solution. OK, removed. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 5/5] mtd: m25p80: add support to parse the partitions by OF node
On Tue, 2010-10-12 at 18:18 +0800, Mingkai Hu wrote: Signed-off-by: Mingkai Hu mingkai...@freescale.com Acked-by: Grant Likely grant.lik...@secretlab.ca --- v4: - Updated to latest kernel base(Linux 2.6.36-rc7). - Made changes according to Grant's comments. Looks good to me, pushed to l2-mtd-2.6.git, thanks. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 15/18] mtd: Fix endianness issues from device tree
On Fri, 2010-10-01 at 17:06 +1000, Ian Munsie wrote: From: Ian Munsie imun...@au1.ibm.com This patch adds the appropriate conversions to correct the endianness issues in the MTD driver whenever it accesses the device tree (which is always big endian). Signed-off-by: Ian Munsie imun...@au1.ibm.com Pushed to l2-mtd-2.6.git, thanks! -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote: On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 r61...@freescale.com wrote: What is the different for unsigned int and u32? I think they are same. Roy, please don't ever write code that assumes that sizeof(int) == 4. There's a reason why we have unsized integer types (like int, long, and short) and sized integer types (like u8, u16, u32). If you want an integer of a specific size, you should use a sized integer type. Yes, sizeof(int) == 4 assumption is not good. But sizeof(int) = 4 is perfectly fine. It is OK to rely on the fact that unsigned int is _at least_ 32-bit, not less. And if you know 32 bits is enough, and you are fine with more, it is _better_ to avoid u32. Simply because with unsigned int you do not limit the compiler and CPU and let them use native integers, rather than strictly 32-bit. This potentially gives the compiler and CPU more room for optimization. I see people use u32 and the friends too much. It is safe and better to use native types, unless you really have to make the variable to be strictly u32. I did not follow this particular conversation and do not judge which type is better in this case. I am talking in general. :-) -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
On Mon, 2010-09-13 at 09:35 -0500, Timur Tabi wrote: On Mon, Sep 13, 2010 at 9:27 AM, Artem Bityutskiy dedeki...@gmail.com wrote: Yes, sizeof(int) == 4 assumption is not good. But sizeof(int) = 4 is perfectly fine. I have to disagree. I don't see how you can say that == is not okay, but = is okay. If I assume that int == 4, which is true for all platform ATM, and will most probably stay true for very long time, I still make an unnecessary assumption which C99 does not guarantee. This is just not very clean. So for things which require exactly 32 bits, u32 or C99 uint32_t should be used. On the other hand, if a have a local variable var which needs to store values which I know will always fit 32 bits, and I do not use it in operations (I/O, etc) which require exactly 32 bits, it is better to use unsigned int for it. Unsigned int is reliably = 4 in Linux. This is wat I meant that sizeof(int) = 4 is perfectly fine. One everywhere, of course, but in many cases. To put it differently, if there is no special reason to limit the variable by exactly 32 bits, it is better to use int. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
On Mon, 2010-09-13 at 13:36 -0500, Timur Tabi wrote: On Mon, Sep 13, 2010 at 11:45 AM, Artem Bityutskiy dedeki...@gmail.com wrote: Unsigned int is reliably = 4 in Linux. Not exactly. sizeof(unsigned int) is effectively never greater than 4 in Linux I know and said the same in the other paragraph which you cut. (I think it's still 32 bits even on a 64-bit kernel) Yes. , so it makes no sense to say =. So since you can't say that sizeof(int) == 4, and you can't say that sizeof(int) 4, then you certainly can't say that sizeof(int) = 4. It also makes no sense to send makes no sense answer 2 times in a row and it makes no sense to not read and not try to understand the e-mail you are replying (even though the english of the writer is not perfect) So it makes no sense to continue arguing. But it makes some sense to go sleep, good night. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
On Mon, 2010-08-09 at 15:33 +0800, Zang Roy-R61911 wrote: Any comment about this serial patches? If none, I'd ask Andrew to merge to his mm tree. Could you please separate out MTD stuff, to the extent it is possible to do? -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code
On Fri, 2010-07-16 at 10:20 -0400, Josh Boyer wrote: On Fri, Jul 16, 2010 at 02:29:02PM +0200, Christian Dietrich wrote: The config options for REDWOOD_[456] were commented out in the powerpc Kconfig. The ifdefs referencing this options therefore are dead and all references to this can be removed (Also dependencies in other KConfig files). Signed-off-by: Christian Dietrich qy03f...@stud.informatik.uni-erlangen.de Signed-off-by: Christoph Egger sicce...@cs.fau.de This seems fine with me. The only question is which tree it coms through. I'm happy to take it in via mine if the netdev and MTD people are fine with that. Otherwise, my ack is below. Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com You know how slow MTD people may be sometimes, so I'd suggest you to merge this via whatever tree. David is in CC, he'll complain if he is unhappy, I think. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
On Tue, 2010-06-22 at 20:57 +0400, Anton Vorontsov wrote: Since commit 18c6182bae0acca220ed6611f741034d563cd19f (Rework probing/JEDEC code), m25p80 driver successfully registers chips even if JEDEC probing fails. This was needed to support non-JEDEC flashes. Though, it appears that some platforms (e.g. blackfin bf533 stamp[1]) used the old behavior to detect if there's any flash connected, so the driver have to fail on JEDEC probing errors. This patch restores the old behavior for JEDEC flashes, and adds -nonjedec SPI device IDs for M25Pxx flashes, so that the kernel still supports non-JEDEC flashes. [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_item_id=5975 Reported-by: Mingquan Pan Reported-by: Barry Song 21cn...@gmail.com Signed-off-by: Anton Vorontsov avoront...@mvista.com --- Pushed both patches to my l2-mtd-2.6.git / dunno, added Mike's ack. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH resend] mpc5121_nfc: Changed SVR check to allow MPC5123.
On Wed, 2010-05-05 at 13:48 -0500, Steve Deiters wrote:
The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
revision 2.
Signed-off-by: Steve Deiters stevedeit...@basler.com
---
drivers/mtd/nand/mpc5121_nfc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c
b/drivers/mtd/nand/mpc5121_nfc.c
index 191bf99..dc04d74 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -666,10 +666,10 @@ static int __devinit mpc5121_nfc_probe(struct
of_device *op,
/*
* Check SoC revision. This driver supports only NFC
- * in MPC5121 revision 2.
+ * in MPC5121 revision 2 and MPC5123 revision 3.
*/
rev = (mfspr(SPRN_SVR) 4) 0xF;
- if (rev != 2) {
+ if ((rev != 2) (rev != 3)) {
dev_err(dev, SoC revision %u is not supported!\n,
rev);
return -ENXIO;
}
Now your patch is line-wrapped. But I fixed it and pushed to
l2-mtd-2.6.git / master.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc5121_nfc: Changed SVR check to allow MPC5123.
On Wed, 2010-04-28 at 17:33 -0500, Steve Deiters wrote: The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121 revision 2. --- drivers/mtd/nand/mpc5121_nfc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Please, add your Signed-off-by and re-send. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 04/11] mtd: Add MPC5121 NAND Flash Controller driver
On Tue, 2010-02-09 at 19:42 -0700, Grant Likely wrote: On Fri, Feb 5, 2010 at 6:42 AM, Anatolij Gustschin ag...@denx.de wrote: Adds NAND Flash Controller driver for MPC5121 Revision 2. All device features, except hardware ECC and power management, are supported. Signed-off-by: Piotr Ziecik ko...@semihalf.com Signed-off-by: Wolfgang Denk w...@denx.de Signed-off-by: Anatolij Gustschin ag...@denx.de Cc: linux-...@lists.infradead.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: John Rigby jcri...@gmail.com On *very* brief review... Acked-by: Grant Likely grant.lik...@secretlab.ca David, there are ordering issues on this patch with arch-specific code. If the patch looks okay to you, then can I pick it up into my tree? Because of the general large response time of the MTD community, I suggest you to go put this stuff to your tree. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 04/11] mtd: Add MPC5121 NAND Flash Controller driver
On Mon, 2010-02-15 at 18:35 +0100, Anatolij Gustschin wrote: Adds NAND Flash Controller driver for MPC5121 Revision 2. All device features, except hardware ECC and power management, are supported. Signed-off-by: Piotr Ziecik ko...@semihalf.com Signed-off-by: Wolfgang Denk w...@denx.de Signed-off-by: Anatolij Gustschin ag...@denx.de Acked-by: Grant Likely grant.lik...@secretlab.ca Cc: linux-...@lists.infradead.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: John Rigby jcri...@gmail.com --- Changes since v3: - include 'asm/mpc5121.h' header instead of 'asm/mpc5xxx.h'. This change is needed because arch patch adding reset module definition was reworked and doesn't add mpc5121 specific definitions to common header for mpc52xx/mpc5121. Changes since v2: - move the arch bits into separate patch (it is the next patch in this series now) - use __devinit/__devexit/__devexit_p and __devinitdata Changes since v1: - add logfile with changes since previous version Changes since the patch version submitted in May 2009: - move mpc5121_nfc.h to the driver .c as there is only one user - remove DRV_VERSION macro - replace printk() by dev_*() - drop unnecessary .suspend and .resume initializations - remove duplicate .name/.owner settings - fix mpc5121_nfc_init() to return of_register_platform_driver(mpc5121_nfc_driver); - move module_init() to just below the init function - remove MODULE_VERSION - use mtd: Add MPC5121 NAND Flash Controller driver as the subject, previously it was mpc5121: Added NAND Flash Controller driver. drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/mpc5121_nfc.c | 916 3 files changed, 924 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/mpc5121_nfc.c Pushed to my l2-mtd-2.6.git / dunno. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] eLBC NAND: increase bus timeout to maximum
On Fri, 2009-11-13 at 14:12 -0600, Scott Wood wrote: When a NAND operation is in progress, all other localbus operations (including NOR flash) will have to wait for access to the bus. However, the NAND operation may take longer to complete than the default timeout. Thus, if NOR is accessed while a NAND operation is in progress, the NAND operation will fail. Signed-off-by: Scott Wood scottw...@freescale.com Taken the patches to my l2-mtd-2.6 tree. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/6] Device table matching for SPI subsystem
On Wed, 2009-08-19 at 01:44 +0400, Anton Vorontsov wrote: On Mon, Aug 10, 2009 at 10:35:23AM +0300, Artem Bityutskiy wrote: On Fri, 2009-07-31 at 04:39 +0400, Anton Vorontsov wrote: Andrew, This new patch set overwrites following patches: hwmon-lm70-convert-to-device-table-matching.patch hwmon-adxx-convert-to-device-table-matching.patch spi-merge-probe-and-probe_id-callbacks.patch spi-prefix-modalias-with-spi.patch of-remove-stmm25p40-alias.patch mtd-m25p80-convert-to-device-table-matching.patch spi-add-support-for-device-table-matching.patch Are you going to send v3 and address David's comments? No v3, but I'm going to address David's comments in a follow up patch set where I'll change the probing code anyway. Do you want some of these patches to go via the MTD tree or they better go as a series via some other tree? Um.. The MTD patches depend on SPI subsystem changes... If David and Andrew are OK with SPI patches going through MTD tree, then I'm fine with it as well. If you are not sure, then I suggest to make these go through something else (not MTD tree). -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 0/6] Device table matching for SPI subsystem
On Fri, 2009-07-31 at 04:39 +0400, Anton Vorontsov wrote: Andrew, This new patch set overwrites following patches: hwmon-lm70-convert-to-device-table-matching.patch hwmon-adxx-convert-to-device-table-matching.patch spi-merge-probe-and-probe_id-callbacks.patch spi-prefix-modalias-with-spi.patch of-remove-stmm25p40-alias.patch mtd-m25p80-convert-to-device-table-matching.patch spi-add-support-for-device-table-matching.patch Are you going to send v3 and address David's comments? Do you want some of these patches to go via the MTD tree or they better go as a series via some other tree? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
On Mon, 2009-08-10 at 18:19 +0200, Wolfram Sang wrote: On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote: On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote: On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sangw.s...@pengutronix.de wrote: Use physmap_of to access RAMs as mtd and add documenation for it. This approach is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the device tree anyhow, extending physmap_of seems to be the cleanest approach. Tested with a phyCORE-MPC5121e. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Looks good to me. Acked-by: Grant Likely grant.lik...@secretlab.ca This patch is sitting in my l2-mtd-2.6.git tree. Great, thanks a lot (and for your l2-tree in general!). One question: Are the additional Acked-bys added later? I could think they might be useful for David's review... Well, I do not bother maintaining nice history there, so rebase it freely, which means I can add your ack. Will do tomorrow. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
On 08/10/2009 07:19 PM, Wolfram Sang wrote: On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote: On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote: On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sangw.s...@pengutronix.de wrote: Use physmap_of to access RAMs as mtd and add documenation for it. This approach is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the device tree anyhow, extending physmap_of seems to be the cleanest approach. Tested with a phyCORE-MPC5121e. Signed-off-by: Wolfram Sangw.s...@pengutronix.de Looks good to me. Acked-by: Grant Likelygrant.lik...@secretlab.ca This patch is sitting in my l2-mtd-2.6.git tree. Great, thanks a lot (and for your l2-tree in general!). One question: Are the additional Acked-bys added later? I could think they might be useful for David's review... Added Acked-by: Grant Likelygrant.lik...@secretlab.ca -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote: On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sangw.s...@pengutronix.de wrote: Use physmap_of to access RAMs as mtd and add documenation for it. This approach is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the device tree anyhow, extending physmap_of seems to be the cleanest approach. Tested with a phyCORE-MPC5121e. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Looks good to me. Acked-by: Grant Likely grant.lik...@secretlab.ca This patch is sitting in my l2-mtd-2.6.git tree. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH Resend2] Remove 'SBC8240 Wind River' Device Driver Code
On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote: Hi, Is there somebody else whom i should also address to get an attention for this patch ? I apolozise if i have not included someone. Kindly connect to the concerned. I'm putting your patch to l2-mtd-2.6.git. -- Best regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH Resend2] Remove 'SBC8240 Wind River' Device Driver Code
Subrata Modak wrote: On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote: On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote: Hi, Is there somebody else whom i should also address to get an attention for this patch ? I apolozise if i have not included someone. Kindly connect to the concerned. I'm putting your patch to l2-mtd-2.6.git. Thanks very much. Would i receive some automatic confirmation once it make to Linus tree ? I do not think so. I'm not MTD maintainer and in l2-mtd-2.6.git I just collect random patches, which the maintainer then usually takes from my tree. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH Resend2] Remove 'SBC8240 Wind River' Device Driver Code
On Fri, 2009-07-10 at 12:42 +0530, Subrata Modak wrote: On Fri, 2009-07-10 at 09:18 +0300, Artem Bityutskiy wrote: Subrata Modak wrote: On Fri, 2009-07-10 at 08:59 +0300, Artem Bityutskiy wrote: On Mon, 2009-07-06 at 07:47 +0530, Subrata Modak wrote: Hi, Is there somebody else whom i should also address to get an attention for this patch ? I apolozise if i have not included someone. Kindly connect to the concerned. I'm putting your patch to l2-mtd-2.6.git. Thanks very much. Would i receive some automatic confirmation once it make to Linus tree ? I do not think so. I'm not MTD maintainer and in l2-mtd-2.6.git I just collect random patches, which the maintainer then usually takes from my tree. Thanks. I just want this through before 2.6.31 stable is released, so that the build fails does not occur on next trees based on that stable one. Then you should bug dwmw2. -- Best regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, 2009-04-16 at 19:38 +0100, David Woodhouse wrote: On Thu, 16 Apr 2009, Artem Bityutskiy wrote: On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote: On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese s...@denx.de wrote: On Thursday 16 April 2009, Grant Likely wrote: Signed-off-by: Stefan Roese s...@denx.de Reviewd-by: Grant Likely grant.lik...@secretlab.ca Yup, still looks good to me. What boards has this been tested on? I tested this version on PPC405EX Kilauea equipped only one standard Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360 board (kmeter1) which is equipped with the Intel P30 part mentioned in the bindings description. Slightly modified since this board support is not yet pushed upstream and currently using v2.6.28 (physmap_of.c has received minor modifications after 2.6.28 release). Okay. It will be good to get this one into -next for some testing exposure. Unless he asks me to do otherwise, I'll leave this one to David to pick up. David usually picks up stuff just before or during merge window, so if you want linux-next exposure, you need to have some extra care. I don't necessarily do that on purpose; it just works out that way when I'm busy. Yeah, not that I try to blame you, but I think we need to expose stuff to linux-next. And people who send patches are frustrated when their stuff gets no attention for very long time. I understand that MTD tree maintenance is a burden, and you are very busy, and no one pays you for this job. Thanks for doing it! I'm going to try to help you. I've just created a git tree where I'll push patches I consider OK and I approve. Here it is: git://git.infradead.org/users/dedekind/l2-mtd-2.6.git My hope is that you would look at that tree from time to time and pull it. At least you may be sure I looked at the patches and did some validation. This should save your time and help MTD users. Thanks. -- Best regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote: This patchset adds support to handle multiple non-identical chips in one flash device tree node. It also adds concat support to physmap_of. This makes it possible to support e.g. the Intel P30 48F4400 chip which internally consists of 2 non-identical NOR chips on one die. Additionally partitions now can span over multiple chips: mtd: physmap_of: Add multiple regions and concatenation support mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt mtd/powerpc: Describe multiple reg tuples usage v2 addresses all comments from Grant Likely, including factoring out the MTD dts bindings documentation into a separate file. v3 addresses all comments (again from Grant). Sorry for my ignorance, but could you please explain why regions exists as an MTD concept? Why different regions could not be represented as different MTD devices? The benefit is - simplicity. Thanks. -- Best regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, 2009-04-16 at 14:52 +0200, Stefan Roese wrote: On Thursday 16 April 2009, Artem Bityutskiy wrote: On Thu, 2009-04-16 at 14:05 +0200, Stefan Roese wrote: This patchset adds support to handle multiple non-identical chips in one flash device tree node. It also adds concat support to physmap_of. This makes it possible to support e.g. the Intel P30 48F4400 chip which internally consists of 2 non-identical NOR chips on one die. Additionally partitions now can span over multiple chips: mtd: physmap_of: Add multiple regions and concatenation support mtd/powerpc: Factor out MTD physmap bindings into mtd-physmap.txt mtd/powerpc: Describe multiple reg tuples usage v2 addresses all comments from Grant Likely, including factoring out the MTD dts bindings documentation into a separate file. v3 addresses all comments (again from Grant). Sorry for my ignorance, but could you please explain why regions exists as an MTD concept? Why different regions could not be represented as different MTD devices? The benefit is - simplicity. The result of these multiple reg tuples *is* multiple MTD devices. Not sure if this explains your comment/question. Please let me know if you still have some comments. OK, I was confused. In MTD there is a weird notion of region. See 'struct mtd_info': /* Data for variable erase regions. If numeraseregions is zero, * it means that the whole device has erasesize as given above. */ int numeraseregions; struct mtd_erase_region_info *eraseregions; in include/linux/mtd/mtd.h I thought you use that, and wanted to realize why is that region notion needed. -- Best regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote: On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese s...@denx.de wrote: On Thursday 16 April 2009, Grant Likely wrote: Signed-off-by: Stefan Roese s...@denx.de Reviewd-by: Grant Likely grant.lik...@secretlab.ca Yup, still looks good to me. What boards has this been tested on? I tested this version on PPC405EX Kilauea equipped only one standard Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360 board (kmeter1) which is equipped with the Intel P30 part mentioned in the bindings description. Slightly modified since this board support is not yet pushed upstream and currently using v2.6.28 (physmap_of.c has received minor modifications after 2.6.28 release). Okay. It will be good to get this one into -next for some testing exposure. Unless he asks me to do otherwise, I'll leave this one to David to pick up. David usually picks up stuff just before or during merge window, so if you want linux-next exposure, you need to have some extra care. -- Best regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
