linux-stable.git/drivers/mtd/chips, branch v4.4.136 Linux kernel stable tree mtd: cfi: cmdset_0002: Do not allow read/write to suspend erase block. 2018-05-02T14:53:42+00:00 Joakim Tjernlund joakim.tjernlund@infinera.com 2018-03-01T13:39:41+00:00 fc1584670f289d3cc9e2c17c0d6ba3a24ae5b785 commit 7b70eb14392a7cf505f9b358d06c33b5af73d1e7 upstream. Currently it is possible to read and/or write to suspend EB's. Writing /dev/mtdX or /dev/mtdblockX from several processes may break the flash state machine. Taken from cfi_cmdset_0001 driver. Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Cc: <stable@vger.kernel.org> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7b70eb14392a7cf505f9b358d06c33b5af73d1e7 upstream.

Currently it is possible to read and/or write to suspend EB's.
Writing /dev/mtdX or /dev/mtdblockX from several processes may
break the flash state machine.

Taken from cfi_cmdset_0001 driver.

Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: cfi: cmdset_0001: Workaround Micron Erase suspend bug. 2018-05-02T14:53:42+00:00 Joakim Tjernlund joakim.tjernlund@transmode.se 2018-03-01T13:39:40+00:00 d519eb768c1e17f1494d539eafdc6c4f0ba318b2 commit 46a16a2283f9e678a4e26829175e0c37a5191860 upstream. Some Micron chips does not work well wrt Erase suspend for boot blocks. This avoids the issue by not allowing Erase suspend for the boot blocks for the 28F00AP30(1GBit) chip. Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Cc: <stable@vger.kernel.org> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 46a16a2283f9e678a4e26829175e0c37a5191860 upstream.

Some Micron chips does not work well wrt Erase suspend for
boot blocks. This avoids the issue by not allowing Erase suspend
for the boot blocks for the 28F00AP30(1GBit) chip.

Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: cfi: cmdset_0001: Do not allow read/write to suspend erase block. 2018-05-02T14:53:42+00:00 Joakim Tjernlund joakim.tjernlund@transmode.se 2018-03-01T13:39:39+00:00 869a31dfe4187038fe3b6033e70141a5e5739ada commit 6510bbc88e3258631831ade49033537081950605 upstream. Currently it is possible to read and/or write to suspend EB's. Writing /dev/mtdX or /dev/mtdblockX from several processes may break the flash state machine. Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Cc: <stable@vger.kernel.org> Reviewed-by: Richard Weinberger <richard@nod.at> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6510bbc88e3258631831ade49033537081950605 upstream.

Currently it is possible to read and/or write to suspend EB's.
Writing /dev/mtdX or /dev/mtdblockX from several processes may
break the flash state machine.

Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: jedec_probe: Fix crash in jedec_read_mfr() 2018-04-08T09:51:55+00:00 Linus Walleij linus.walleij@linaro.org 2018-03-03T22:29:03+00:00 123bc8641ee269fb2247ff2a97f276fcab179182 commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream. It turns out that the loop where we read manufacturer jedec_read_mfd() can under some circumstances get a CFI_MFR_CONTINUATION repeatedly, making the loop go over all banks and eventually hit the end of the map and crash because of an access violation: Unable to handle kernel paging request at virtual address c4980000 pgd = (ptrval) [c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000 Internal error: Oops: 7 [#1] PREEMPT ARM CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150 Hardware name: Gemini (Device Tree) PC is at jedec_probe_chip+0x6ec/0xcd0 LR is at 0x4 pc : [<c03a2bf4>] lr : [<00000004>] psr: 60000013 sp : c382dd18 ip : 0000ffff fp : 00000000 r10: c0626388 r9 : 00020000 r8 : c0626340 r7 : 00000000 r6 : 00000001 r5 : c3a71afc r4 : c382dd70 r3 : 00000001 r2 : c4900000 r1 : 00000002 r0 : 00080000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0000397f Table: 00004000 DAC: 00000053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Fix this by breaking the loop with a return 0 if the offset exceeds the map size. Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0") Cc: <stable@vger.kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.

It turns out that the loop where we read manufacturer
jedec_read_mfd() can under some circumstances get a
CFI_MFR_CONTINUATION repeatedly, making the loop go
over all banks and eventually hit the end of the
map and crash because of an access violation:

Unable to handle kernel paging request at virtual address c4980000
pgd = (ptrval)
[c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
Internal error: Oops: 7 [#1] PREEMPT ARM
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
Hardware name: Gemini (Device Tree)
PC is at jedec_probe_chip+0x6ec/0xcd0
LR is at 0x4
pc : [<c03a2bf4>]    lr : [<00000004>]    psr: 60000013
sp : c382dd18  ip : 0000ffff  fp : 00000000
r10: c0626388  r9 : 00020000  r8 : c0626340
r7 : 00000000  r6 : 00000001  r5 : c3a71afc  r4 : c382dd70
r3 : 00000001  r2 : c4900000  r1 : 00000002  r0 : 00080000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 0000397f  Table: 00004000  DAC: 00000053
Process swapper (pid: 1, stack limit = 0x(ptrval))

Fix this by breaking the loop with a return 0 if
the offset exceeds the map size.

Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: cfi: enforce valid geometry configuration 2018-02-25T10:03:46+00:00 Arnd Bergmann arnd@arndb.de 2015-11-23T13:39:33+00:00 25bce31b08d1fe7332f2e814472c5eacc5d84d65 commit f5f92b36fbbb8ac7d70ff5fa39ec2637cce3094c upstream. MTD allows compile-time configuration of the possible CFI geometry settings that are allowed by the kernel, but that includes a couple of invalid configurations, where no bank width or no interleave setting is allowed. These are then caught with a compile-time warning: include/linux/mtd/cfi.h:76:2: warning: #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work. include/linux/mtd/map.h:145:2: warning: #warning "No CONFIG_MTD_MAP_BANK_WIDTH_xx selected. No NOR chip support can work" This is a bit annoying for randconfig tests, and can be avoided if we change the Kconfig logic to always select the simplest configuration when no other one is enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f5f92b36fbbb8ac7d70ff5fa39ec2637cce3094c upstream.

MTD allows compile-time configuration of the possible CFI geometry
settings that are allowed by the kernel, but that includes a couple of
invalid configurations, where no bank width or no interleave setting
is allowed. These are then caught with a compile-time warning:

include/linux/mtd/cfi.h:76:2: warning: #warning No CONFIG_MTD_CFI_Ix selected. No NOR chip support can work.
include/linux/mtd/map.h:145:2: warning: #warning "No CONFIG_MTD_MAP_BANK_WIDTH_xx selected. No NOR chip support can work"

This is a bit annoying for randconfig tests, and can be avoided if
we change the Kconfig logic to always select the simplest configuration
when no other one is enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: avoid stack overflow in MTD CFI code 2017-05-08T05:46:01+00:00 Arnd Bergmann arnd@arndb.de 2016-02-29T12:20:28+00:00 fd79e436325841863d070f8e72246b437c0f5a15 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 <arnd@arndb.de> [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 <computersforpeace@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <arnd@arndb.de>
[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 <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mtd: chips: fixup dependencies, to prevent build error 2015-05-28T18:07:48+00:00 Brian Norris computersforpeace@gmail.com 2015-05-28T18:07:48+00:00 bde90062a38160fdce0d51a4340bb93c1a8f1114 Commit 4612c715a6ea ("mtd: cfi: deinline large functions") moved some code into the cfi_util library without creating a new dependency. So we can get build failures like the following, when CONFIG_MTD_JEDECPROBE=y and CONFIG_MTD_CFI_UTIL=m. drivers/built-in.o: In function `jedec_read_id': >> jedec_probe.c:(.text+0x187ed8): undefined reference to `cfi_build_cmd_addr' drivers/built-in.o: In function `jedec_read_mfr': >> jedec_probe.c:(.text+0x187f4a): undefined reference to `cfi_build_cmd_addr' drivers/built-in.o: In function `jedec_reset': >> jedec_probe.c:(.text+0x187fe0): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x188004): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x18802b): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x18804e): undefined reference to `cfi_send_gen_cmd' drivers/built-in.o: In function `jedec_probe_chip': >> jedec_probe.c:(.text+0x188130): undefined reference to `cfi_build_cmd_addr' >> jedec_probe.c:(.text+0x18814d): undefined reference to `cfi_build_cmd_addr' >> jedec_probe.c:(.text+0x1881dc): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x188203): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x18822d): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x1884c0): undefined reference to `cfi_send_gen_cmd' >> jedec_probe.c:(.text+0x1884e7): undefined reference to `cfi_send_gen_cmd' drivers/built-in.o:jedec_probe.c:(.text+0x188511): more undefined references to `cfi_send_gen_cmd' follow drivers/built-in.o: In function `jedec_probe_chip': >> jedec_probe.c:(.text+0x188618): undefined reference to `cfi_build_cmd' So let's express the dependency properly. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 
Commit 4612c715a6ea ("mtd: cfi: deinline large functions") moved some
code into the cfi_util library without creating a new dependency. So we
can get build failures like the following, when CONFIG_MTD_JEDECPROBE=y
and CONFIG_MTD_CFI_UTIL=m.

   drivers/built-in.o: In function `jedec_read_id':
>> jedec_probe.c:(.text+0x187ed8): undefined reference to `cfi_build_cmd_addr'
   drivers/built-in.o: In function `jedec_read_mfr':
>> jedec_probe.c:(.text+0x187f4a): undefined reference to `cfi_build_cmd_addr'
   drivers/built-in.o: In function `jedec_reset':
>> jedec_probe.c:(.text+0x187fe0): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x188004): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x18802b): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x18804e): undefined reference to `cfi_send_gen_cmd'
   drivers/built-in.o: In function `jedec_probe_chip':
>> jedec_probe.c:(.text+0x188130): undefined reference to `cfi_build_cmd_addr'
>> jedec_probe.c:(.text+0x18814d): undefined reference to `cfi_build_cmd_addr'
>> jedec_probe.c:(.text+0x1881dc): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x188203): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x18822d): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x1884c0): undefined reference to `cfi_send_gen_cmd'
>> jedec_probe.c:(.text+0x1884e7): undefined reference to `cfi_send_gen_cmd'
   drivers/built-in.o:jedec_probe.c:(.text+0x188511): more undefined references to `cfi_send_gen_cmd' follow
   drivers/built-in.o: In function `jedec_probe_chip':
>> jedec_probe.c:(.text+0x188618): undefined reference to `cfi_build_cmd'

So let's express the dependency properly.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
mtd: cfi_cmdset_0002: Initialize datum before calling map_word_load_partial 2015-05-27T19:47:37+00:00 Christian Riesch christian.riesch@omicron.at 2015-03-31T21:29:22+00:00 636fdbf88efe069f9951d1b7df8d3fd82060dc60 In do_otp_write we must initialize the variable datum before calling map_word_load_partial. Otherwise the upper bits of datum may be undefined, which later causes problems in chip_good called by do_write_oneword. Signed-off-by: Christian Riesch <christian.riesch@omicron.at> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 
In do_otp_write we must initialize the variable datum before calling
map_word_load_partial. Otherwise the upper bits of datum may be undefined,
which later causes problems in chip_good called by do_write_oneword.

Signed-off-by: Christian Riesch <christian.riesch@omicron.at>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
mtd: cfi: deinline large functions 2015-05-27T19:42:16+00:00 Denys Vlasenko dvlasenk@redhat.com 2015-05-18T10:58:40+00:00 4612c715a6ea6b3af2aee0163c0721375b2548d7 With this .config: http://busybox.net/~vda/kernel_config, after uninlining these functions have sizes and callsite counts as follows: cfi_udelay(): 74 bytes, 26 callsites cfi_send_gen_cmd(): 153 bytes, 95 callsites cfi_build_cmd(): 274 bytes, 123 callsites cfi_build_cmd_addr(): 49 bytes, 15 callsites cfi_merge_status(): 230 bytes, 3 callsites Reduction in code size is about 50,000: text data bss dec hex filename 85842882 22294584 20627456 128764922 7accbfa vmlinux.before 85789648 22294616 20627456 128711720 7abfc28 vmlinux Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> CC: Dan Carpenter <dan.carpenter@oracle.com> CC: Jingoo Han <jg1.han@samsung.com> CC: Brian Norris <computersforpeace@gmail.com> CC: Aaron Sierra <asierra@xes-inc.com> CC: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> CC: David Woodhouse <David.Woodhouse@intel.com> CC: linux-mtd@lists.infradead.org CC: linux-kernel@vger.kernel.org Signed-off-by: Brian Norris <computersforpeace@gmail.com> 
With this .config: http://busybox.net/~vda/kernel_config,
after uninlining these functions have sizes and callsite counts
as follows:

cfi_udelay(): 74 bytes, 26 callsites
cfi_send_gen_cmd(): 153 bytes, 95 callsites
cfi_build_cmd(): 274 bytes, 123 callsites
cfi_build_cmd_addr(): 49 bytes, 15 callsites
cfi_merge_status(): 230 bytes, 3 callsites

Reduction in code size is about 50,000:

    text     data      bss       dec     hex filename
85842882 22294584 20627456 128764922 7accbfa vmlinux.before
85789648 22294616 20627456 128711720 7abfc28 vmlinux

Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: Dan Carpenter <dan.carpenter@oracle.com>
CC: Jingoo Han <jg1.han@samsung.com>
CC: Brian Norris <computersforpeace@gmail.com>
CC: Aaron Sierra <asierra@xes-inc.com>
CC: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
CC: David Woodhouse <David.Woodhouse@intel.com>
CC: linux-mtd@lists.infradead.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
mtd: cfi: clean up some indenting 2015-03-31T01:01:04+00:00 Dan Carpenter dan.carpenter@oracle.com 2015-02-25T13:15:58+00:00 35cc3337b6d5bb71ec80daaaf268bf25514fb6a2 These lines were all indented one tab more than they should be. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> 
These lines were all indented one tab more than they should be.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>