Files
odroid-linux/include/linux
Arnd Bergmann fddcca5107 mtd: avoid stack overflow in MTD CFI code
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>
2016-04-03 16:46:24 -07:00
..
2016-03-25 18:51:55 +01:00
2015-10-17 21:22:08 -07:00
2015-10-07 18:08:15 +01:00
2016-03-04 23:50:27 -06:00
2015-12-23 08:37:10 -07:00
2016-02-11 10:07:18 -05:00
2016-03-15 16:55:16 -07:00
2015-12-22 09:38:34 -07:00
2016-03-20 09:34:02 -06:00
2015-12-06 12:46:31 +01:00
2016-03-08 15:28:31 -05:00
2016-03-11 21:19:16 +08:00
2016-02-16 13:04:58 -05:00
2016-02-26 13:28:35 +02:00
2015-12-28 13:41:50 +01:00
2016-01-15 17:56:32 -08:00
2015-11-25 09:22:00 -07:00
2016-03-11 14:58:58 -05:00
2015-10-23 05:44:28 -07:00
2016-02-11 09:59:22 -05:00
2016-03-22 15:36:02 -07:00
2015-10-01 15:06:43 +02:00
2015-12-14 10:03:46 +01:00
2016-01-28 14:19:12 -08:00
2016-03-25 16:37:42 -07:00
2016-03-22 15:36:02 -07:00
2016-02-16 13:04:58 -05:00
2016-03-22 15:36:02 -07:00
2015-07-28 08:50:42 +01:00
2016-01-15 17:56:32 -08:00
2016-03-09 15:43:42 -08:00
2016-01-15 17:56:32 -08:00
2015-10-27 18:55:31 -07:00
2016-03-25 16:37:42 -07:00
2015-10-20 22:10:45 +08:00
2015-07-21 10:39:05 -07:00
2016-03-05 12:24:06 -08:00
2016-03-09 16:36:13 -05:00
2016-03-17 14:57:16 -04:00
2016-02-08 15:20:01 -05:00
2016-02-16 13:04:58 -05:00
2015-09-10 13:29:01 -07:00
2016-02-11 18:35:48 -08:00
2016-02-11 18:35:48 -08:00
2016-03-14 15:43:11 -04:00
2016-02-10 01:11:54 +01:00
2016-03-09 15:15:32 -08:00
2015-10-06 17:08:19 +02:00
2016-02-16 13:04:58 -05:00
2015-10-22 08:59:18 -07:00
2016-03-17 15:09:34 -07:00
2016-03-09 16:36:13 -05:00
2015-11-16 09:23:47 +01:00
2016-03-22 15:36:02 -07:00
2016-03-22 15:36:02 -07:00
2016-03-22 15:36:02 -07:00
2016-01-10 22:13:15 -05:00
2016-01-04 16:11:11 -05:00
2016-03-25 16:37:42 -07:00
2016-03-25 16:37:42 -07:00
2016-03-25 16:37:42 -07:00
2016-03-17 15:09:34 -07:00
2016-03-18 14:10:57 +08:00
2015-08-17 11:25:28 -07:00
2015-10-01 09:57:59 -07:00
2015-10-19 01:01:21 +02:00
2016-01-28 14:13:44 -08:00
2015-11-23 09:44:58 +01:00
2016-02-22 16:10:08 -07:00
2016-01-14 16:00:49 -08:00
2015-12-03 07:24:29 -08:00
2015-09-08 15:35:28 -07:00