user/sven/linux.git/include/linux/mtd, branch v4.4.125

mtd: sh_flctl: pass FIFO as physical address

2018-02-25T10:03:46Z

commit 1873315fb156cbc8e46f28e8b128f17ff6c31728 upstream. By convention, the FIFO address we pass using dmaengine_slave_config is a physical address in the form that is understood by the DMA engine, as a dma_addr_t, phys_addr_t or resource_size_t. The sh_flctl driver however passes a virtual __iomem address that gets cast to dma_addr_t in the slave driver. This happens to work on shmobile because that platform sets up an identity mapping for its MMIO regions, but such code is not portable to other platforms, and prevents us from ever changing the platform mapping or reusing the driver on other architectures like ARM64 that might not have the mapping. We also get a warning about a type mismatch for the case that dma_addr_t is wider than a pointer, i.e. when CONFIG_LPAE is set: drivers/mtd/nand/sh_flctl.c: In function 'flctl_setup_dma': drivers/mtd/nand/sh_flctl.c:163:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl); This changes the driver to instead pass the physical address of the FIFO that is extracted from the MMIO resource, making the code more portable and avoiding the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: cfi: convert inline functions to macros

2018-02-16T19:09:41Z

commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream. The map_word_() functions, dating back to linux-2.6.8, try to perform bitwise operations on a 'map_word' structure. This may have worked with compilers that were current then (gcc-3.4 or earlier), but end up being rather inefficient on any version I could try now (gcc-4.4 or higher). Specifically we hit a problem analyzed in gcc PR81715 where we fail to reuse the stack space for local variables. This can be seen immediately in the stack consumption for cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN) can be up to 2200 bytes. Changing the inline functions into macros brings this down to 1280 bytes. Without KASAN, the same problem exists, but the stack consumption is lower to start with, my patch shrinks it from 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word structures for each call to one of these helpers. With the latest gcc-8 snapshot, the problem is fixed in upstream gcc, but nobody uses that yet, so we should still work around it in mainline kernels and probably backport the workaround to stable kernels as well. We had a couple of other functions that suffered from the same gcc bug, and all of those had a simpler workaround involving dummy variables in the inline function. Unfortunately that did not work here, the macro hack was the best I could come up with. It would also be helpful to have someone to a little performance testing on the patch, to see how much it helps in terms of CPU utilitzation. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 Signed-off-by: Arnd Bergmann Acked-by: Richard Weinberger Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman

mtd: avoid stack overflow in MTD CFI code

2017-05-08T05:46:01Z

commit fddcca5107051adf9e4481d2a79ae0616577fd2c upstream. When map_word gets too large, we use a lot of kernel stack, and for MTD_MAP_BANK_WIDTH_32, this means we use more than the recommended 1024 bytes in a number of functions: drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers': drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_erase_varsize': drivers/mtd/chips/cfi_cmdset_0020.c:972:1: warning: the frame size of 1208 bytes is larger than 1024 bytes [-Wframe-larger-than=] drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer': drivers/mtd/chips/cfi_cmdset_0001.c:1835:1: warning: the frame size of 1240 bytes is larger than 1024 bytes [-Wframe-larger-than=] This can be avoided if all operations on the map word are done indirectly and the stack gets reused between the calls. We can mostly achieve this by selecting MTD_COMPLEX_MAPPINGS whenever MTD_MAP_BANK_WIDTH_32 is set, but for the case that no other bank width is enabled, we also need to use a non-constant map_bankwidth() to convince the compiler to use less stack. Signed-off-by: Arnd Bergmann [Brian: this patch mostly achieves its goal by forcing MTD_COMPLEX_MAPPINGS (and the accompanying indirection) for 256-bit mappings; the rest of the change is mostly a wash, though it helps reduce stack size slightly. If we really care about supporting 256-bit mappings though, we should consider rewriting some of this code to avoid keeping and assigning so many 256-bit objects on the stack.] Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman

mtd: spi-nor: fix Spansion regressions (aliased with Winbond)

2016-01-06T00:00:03Z

Spansion and Winbond have occasionally used the same manufacturer ID, and they don't support the same features. Particularly, writing SR=0 seems to break read access for Spansion's s25fl064k. Unfortunately, we don't currently have a way to differentiate these Spansion and Winbond parts, so rather than regressing support for these Spansion flash, let's drop the new Winbond lock/unlock support for now. We can try to address Winbond support during the next release cycle. Original discussion: http://patchwork.ozlabs.org/patch/549173/ http://patchwork.ozlabs.org/patch/553683/ Fixes: 357ca38d4751 ("mtd: spi-nor: support lock/unlock/is_locked for Winbond") Fixes: c6fc2171b249 ("mtd: spi-nor: disable protection for Winbond flash at startup") Signed-off-by: Brian Norris Reported-by: Felix Fietkau Cc: Felix Fietkau

mtd: spi-nor: add mtd_is_locked() support

2015-10-14T01:22:54Z

This enables ioctl(MEMISLOCKED). Status can now be reported in the mtdinfo or flash_lock utilities found in mtd-utils. Signed-off-by: Brian Norris

mtd: spi-nor: fixup kernel-doc for flash lock/unlock function pointers

2015-10-14T01:22:53Z

I got the names of these fields wrong. Signed-off-by: Brian Norris

mtd: spi-nor: add SPI NOR manufacturer IDs

2015-10-14T01:22:51Z

These are often similar for CFI (parallel NOR) and for SPI NOR, but they aren't always the same, for various reasons (different namespaces, company acquisitions and renames, etc.). And some don't have CFI_MFR_* entries at all. So let's make a proper place to list the SPI NOR IDs, with all the SPI NOR specific assumptions and comments. Signed-off-by: Brian Norris

mtd: spi-nor: make bitfield constants more consistent

2015-10-14T01:22:51Z

These status bits use different ways of representing similar integer constants -- some are decimal, some are hex. Make them more consistent. At the same time, impose my own preference, since IMO it's clearer what these are when using the BIT() macro. Signed-off-by: Brian Norris

mtd: spi-nor: make implicit dependency explicit

2015-10-14T01:22:50Z

We use BIT() in the header. No real problem for now, but it's better to be accurate. Signed-off-by: Brian Norris

mtd: nand: pass page number to ecc->write_xxx() methods

2015-10-13T19:56:49Z

The ->read_xxx() methods are all passed the page number the NAND controller is supposed to read, but ->write_xxx() do not have such a parameter. This is a problem if we want to properly implement data scrambling/randomization in order to mitigate MLC sensibility to repeated pattern: to prevent bitflips in adjacent pages in the same block we need to avoid repeating the same pattern at the same offset in those pages, hence the randomizer/scrambler engine need to be passed the page value in order to adapt its seed accordingly. Moreover, adding the page parameter to the ->write_xxx() methods add some consistency to the current API. Signed-off-by: Boris Brezillon CC: Josh Wu CC: Ezequiel Garcia CC: Maxime Ripard CC: Greg Kroah-Hartman CC: Huang Shijie CC: Stefan Agner CC: devel@driverdev.osuosl.org CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org Signed-off-by: Brian Norris