1. 09 Jul, 2016 1 commit
  2. 03 Apr, 2016 1 commit
    • Arnd Bergmann's avatar
      mtd: avoid stack overflow in MTD CFI code · fddcca51
      Arnd Bergmann authored
      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: default avatarArnd 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
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  3. 06 Jan, 2016 1 commit
  4. 18 Dec, 2015 1 commit
  5. 30 Nov, 2015 1 commit
    • Arnd Bergmann's avatar
      mtd: cfi: enforce valid geometry configuration · f5f92b36
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  6. 28 May, 2015 1 commit
    • Brian Norris's avatar
      mtd: chips: fixup dependencies, to prevent build error · bde90062
      Brian Norris authored
      Commit 4612c715 ("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: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  7. 27 May, 2015 2 commits
  8. 30 Mar, 2015 1 commit
  9. 10 Jan, 2015 1 commit
  10. 09 Jan, 2015 1 commit
  11. 25 Nov, 2014 1 commit
  12. 29 Oct, 2014 1 commit
    • Dmitry Eremin-Solenikov's avatar
      mtd: cfi_cmdset_0001.c: fix resume for LH28F640BF chips · 89cf38dd
      Dmitry Eremin-Solenikov authored
      After '#echo mem > /sys/power/state' some devices can not be properly resumed
      because apparently the MTD Partition Configuration Register has been reset
      to default thus the rootfs cannot be mounted cleanly on resume.
      An example of this can be found in the SA-1100 Developer's Manual at
      where the second step of the Sleep Shutdown Sequence is described:
      "An internal reset is applied to the SA-1100. All units are reset...".
      As workaround we refresh the PCR value as done initially on chip setup.
      This behavior and the fix are confirmed by our tests done on 2 different Zaurus
      collie units with kernel 3.17.
      Fixes: 812c5fa8: ("mtd: cfi_cmdset_0001.c: add support for Sharp LH28F640BF NOR")
      Signed-off-by: default avatarDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Signed-off-by: default avatarAndrea Adami <andrea.adami@gmail.com>
      Cc: <stable@vger.kernel.org> # 3.16+
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  13. 19 Aug, 2014 1 commit
  14. 15 Aug, 2014 1 commit
  15. 16 Jul, 2014 1 commit
    • Bean Huo's avatar
      mtd: cfi_cmdset_0002: fix do_write_buffer() timeout error · 6534e680
      Bean Huo authored
      For some NOR flashes, the size of the buffer program has been increased
      from 256 bytes to 512 bytes, and so 2ms maximum timeout can may not be
      sufficient for all different vendor's NOR flash. There is maximum
      timeout information in the CFI area, so we instead of picking a fixed
      value, we can calculate this according to the standard CFI parameters
      parsed at probe time. If we haven't probed this information, or it is
      smaller than 2000us, then specify a minimum value 2000us.
      Tested with Micron JS28F512M29EWx and Micron MT28EW512ABA flash devices.
      Signed-off-by: default avatarBean Huo <beanhuo@outlook.com>
      [Brian: fix up comments, use 'max()']
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  16. 13 Jul, 2014 1 commit
  17. 11 Jul, 2014 4 commits
  18. 20 May, 2014 2 commits
  19. 10 Mar, 2014 4 commits
  20. 05 Aug, 2013 3 commits
  21. 05 Apr, 2013 1 commit
    • Artem Bityutskiy's avatar
      mtd: merge mtdchar module with mtdcore · 660685d9
      Artem Bityutskiy authored
      The MTD subsystem has historically tried to be as configurable as possible. The
      side-effect of this is that its configuration menu is rather large, and we are
      gradually shrinking it. For example, we recently merged partitions support with
      the mtdcore.
      This patch does the next step - it merges the mtdchar module to mtdcore. And in
      this case this is not only about eliminating too fine-grained separation and
      simplifying the configuration menu. This is also about eliminating seemingly
      useless kernel module.
      Indeed, mtdchar is a module that allows user-space making use of MTD devices
      via /dev/mtd* character devices. If users do not enable it, they simply cannot
      use MTD devices at all. They cannot read or write the flash contents. Is it a
      sane and useful setup? I believe not. And everyone just enables mtdchar.
      Having mtdchar separate is also a little bit harmful. People sometimes miss the
      fact that they need to enable an additional configuration option to have
      user-space MTD interfaces, and then they wonder why on earth the kernel does
      not allow using the flash? They spend time asking around.
      Thus, let's just get rid of this module and make it part of mtd core.
      Note, mtdchar had additional configuration option to enable OTP interfaces,
      which are present on some flashes. I removed that option as well - it saves a
      really tiny amount space.
      [dwmw2: Strictly speaking, you can mount file systems on MTD devices just
              fine without the mtdchar (or mtdblock) devices; you just can't do
              other manipulations directly on the underlying device. But still I
              agree that it makes sense to make this unconditional. And Yay! we
              get to kill off an instance of checking CONFIG_foo_MODULE, which is
              an abomination that should never happen.]
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  22. 14 Mar, 2013 1 commit
    • Rusty Russell's avatar
      CONFIG_SYMBOL_PREFIX: cleanup. · b92021b0
      Rusty Russell authored
      We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
      "_".  But Al Viro broke this in "consolidate cond_syscall and
      SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
      do so.
      Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
      prefix it so something.  So various places define helpers which are
      defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:
      1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
      2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
      3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
      4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
      5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
      6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
      7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
         CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
         for pasting.
      (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).
      Let's solve this properly:
      1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
      2) Make linux/export.h usable from asm.
      4) Make everyone use them.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Tested-by: James Hogan <james.hogan@imgtec.com> (metag)
  23. 04 Feb, 2013 1 commit
    • Stefan Roese's avatar
      mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking · 1648eaaa
      Stefan Roese authored
      Currently cfi_cmdset_0002.c does not support PPB locking of sectors. This
      patch adds support for this locking/unlocking mechanism. It is needed on
      some platforms, since newer U-Boot versions do support this PPB locking
      and protect for example their environment sector(s) this way.
      This PPB locking/unlocking will be enabled for all devices supported by
      cfi_cmdset_0002 reporting 8 in the CFI word 0x49 (Sector Protect/Unprotect
      Please note that PPB locking does support sector-by-sector locking. But
      the whole chip can only be unlocked together. So unlocking one sector
      will automatically unlock all sectors of this device. Because of this
      chip limitation, the PPB unlocking function saves the current locking
      status of all sectors before unlocking the whole device. After unlocking
      the saved locking status is re-configured. This way only the addressed
      sectors will be unlocked.
      To selectively enable this advanced sector protection mechanism, the
      device-tree property "use-advanced-sector-protection" has been created.
      To enable support for this locking this property needs to be present in the
      flash DT node. E.g.:
      nor_flash@0,0 {
      	compatible = "amd,s29gl256n", "cfi-flash";
      	bank-width = <2>;
      Tested with Spansion S29GL512S10THI and Micron JS28F512M29EWx flash
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Tested-by: default avatarHolger Brunck <holger.brunck@keymile.com>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
  24. 11 Jan, 2013 1 commit
  25. 03 Dec, 2012 1 commit
    • Harald Nordgard-Hansen's avatar
      mtd: fix recovery after failed write-buffer operation in cfi_cmdset_0002.c · 070c3222
      Harald Nordgard-Hansen authored
      When working on a problem with some flash chips that lock up during
      write-buffer operations, I think there may be a bug in the linux
      handling of chips using cfi_cmdset_0002.c.
      The datasheets I have found for a number of these chips all specify that
      when aborting a write-buffer command, it is not enough to use the
      standard reset.  Rather a "write-to-buffer-reset command" is needed.
      This command is quite similar for all chips, the main variance seem to
      be if the final 0xF0 can go to any address or must go to addr_unlock1.
      The bug is then in the recovery handling when timing out at the end of
      do_write_buffer, where using the normal reset command is not sufficient.
      Without this change, if the write-buffer command fails then any
      following operations on the flash also fail.
      Signed-off-by: default avatarHarald Nordgard-Hansen <hhansen@pvv.org>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
  26. 29 Sep, 2012 1 commit
    • Stefan Roese's avatar
      mtd: cfi_cmdset_0001: Fix problem with unlocking timeout · 7be1f6b9
      Stefan Roese authored
      Unlocking may take up to 1.4 seconds on some Intel flashes. So
      lets use a max. of 1.5 seconds (1500ms) as timeout.
      See "Clear Block Lock-Bits Time" on page 40 in
      "3 Volt Intel StrataFlash Memory" 28F128J3,28F640J3,28F320J3 manual
      from February 2003
      This patch also fixes some other problems with this timeout:
      - Don't use HZ in timeout "calculation"!
        While testing we noticed that an unlocking timeout occured with
        HZ=1000 and didn't occur with HZ=300. This was because the
        timeout parameter was calculated differently depending on the
        HZ value. Now a fixed value of 1500ms is used.
      - The last parameter of WAIT_TIMEOUT (defined to
        inval_cache_and_wait_for_operation) has to be passed in
        micro-seconds. So multiply the ms value with 1000 and not 100
        to calculate this value.
      - Use variable name "mdelay" instead of misleading "udelay".
      Signed-off-by: default avatarStefan Roese <sr@denx.de>
      Tested-by: default avatarStephan Gatzka <stephan@gatzka.org>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  27. 16 Jul, 2012 1 commit
  28. 06 Jul, 2012 1 commit
  29. 13 May, 2012 2 commits