1. 21 Nov, 2018 1 commit
    • Arnd Bergmann's avatar
      mtd: docg3: don't set conflicting BCH_CONST_PARAMS option · fbd70354
      Arnd Bergmann authored
      commit be2e1c9d upstream.
      
      I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
      option that is set by DOCG3 breaks setting variable parameters for any
      other users of the BCH library code.
      
      The only other user we have today is the MTD_NAND software BCH
      implementation (most flash controllers use hardware BCH these days
      and are not affected). I considered removing BCH_CONST_PARAMS entirely
      because of the inherent conflict, but according to the description in
      lib/bch.c there is a significant performance benefit in keeping it.
      
      To avoid the immediate problem of the conflict between MTD_NAND_BCH
      and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
      is disabled, which should fix the problem for all cases that
      are affected. This should also work for all stable kernels.
      
      Note that there is only one machine that actually seems to use the
      DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
      the driver disabled, but it almost certainly shows up if we wanted
      to test random kernels on machines that use software BCH in MTD.
      
      Fixes: d13d19ec
      
       ("mtd: docg3: add ECC correction code")
      Cc: stable@vger.kernel.org
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbd70354
  2. 11 May, 2017 1 commit
  3. 19 Jul, 2016 1 commit
    • Rafał Miłecki's avatar
      mtd: add arch dependency for MTD_BCM47XXSFLASH symbol · efacc699
      Rafał Miłecki authored
      We dropped strict MIPS dependency for bcm47xxsflash driver in:
      commit 5651d6aa ("mtd: bcm47xxsflash: use ioremap_cache() instead of
      KSEG0ADDR()") but using ioremap_cache still limits building it to few
      selected architectures only.
      
      A recent commit 57d8f7dd ("bcma: allow enabling serial flash support
      on non-MIPS SoCs") automatically dropped MIPS dependency for
      MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris.
      
      The bcma change is alright as it doesn't break building bcma code in any
      way. MTD_BCM47XXSFLASH on the other hand should be limited to archs
      which need it and can build it (by providing ioremap_cache).
      
      Fixes: 57d8f7dd
      
       ("bcma: allow enabling serial flash support on non-MIPS SoCs")
      Signed-off-by: default avatarRafał Miłecki <zajec5@gmail.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Acked-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      efacc699
  4. 18 Jul, 2016 1 commit
  5. 10 Jul, 2016 1 commit
  6. 11 Jun, 2015 1 commit
  7. 17 Apr, 2014 1 commit
  8. 14 Apr, 2014 3 commits
  9. 20 Mar, 2014 1 commit
  10. 07 Nov, 2013 1 commit
    • Brian Norris's avatar
      mtd: m25p80: remove M25PXX_USE_FAST_READ Kconfig · ddba7c5a
      Brian Norris authored
      
      
      Remove the compile-time option for FAST_READ, since we have run-time
      support for detecting it. This refactors the logic for enabling
      fast-read, such that for DT-enabled devices, we honor the
      "m25p,fast-read" property but for non-DT devices, we default to using
      FAST_READ whenever the flash device supports it.
      
      Normal READ and FAST_READ differ only in the following:
      
        * FAST_READ supports SPI higher clock frequencies [1]
      
        * number of dummy cycles; FAST_READ requires 8 dummy cycles (whereas
          READ requires 0) to allow the flash sufficient setup time, even when
          running at higher clock speeds
      
      Thus, for flash chips which support FAST_READ, there is otherwise no
      limiting reason why we cannot use the FAST_READ opcode instead of READ.
      It simply allows the SPI controller to run at higher clock rates. So
      theoretically, nobody should be needing the compile-time option anyway.
      
        [1] I have a Spansion S25FL128S datasheet which says:
      
          "The maximum operating clock frequency for the READ command is 50
          MHz."
      
        And:
      
          "The maximum operating clock frequency for FAST READ command is 133
          MHz."
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      ddba7c5a
  11. 05 Aug, 2013 1 commit
  12. 05 Apr, 2013 2 commits
    • 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>
      660685d9
    • Artem Bityutskiy's avatar
      mtd: doc: remove support for DoC 2000/2001/2001+ · b5a6c309
      Artem Bityutskiy authored
      
      
      These drivers are deprecated for very long time, and we have a different driver
      for these called "diskonchip". Thus, kill the ancient cruft.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      b5a6c309
  13. 04 Feb, 2013 1 commit
  14. 15 Jan, 2013 1 commit
  15. 11 Jan, 2013 1 commit
  16. 29 Sep, 2012 1 commit
  17. 06 Jul, 2012 1 commit
  18. 26 Mar, 2012 1 commit
  19. 24 Mar, 2012 1 commit
  20. 09 Jan, 2012 2 commits
  21. 30 Oct, 2011 1 commit
    • Paul Bolle's avatar
      mtd: clean up usage of MTD_DOCPROBE_ADDRESS · 6be55f79
      Paul Bolle authored
      
      
      Depending on whether MTD_DOCPROBE_ADVANCED is set or not,
      MTD_DOCPROBE_ADDRESS will default to either 0x0000 or 0. That should
      lead to (basically) identical code in docprobe.c. The current two
      defaults should be merged.
      
      And, while we're at it, if MTD_DOCPROBE is set MTD_DOCPROBE_ADDRESS will
      always be set. (MTD_DOCPROBE_ADDRESS depends on MTD_DOCPROBE and it has
      a default value.) So the check whether CONFIG_MTD_DOCPROBE_ADDRESS is
      defined is unnecessary and should be dropped.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      6be55f79
  22. 14 Oct, 2011 1 commit
    • Robert Jarzmik's avatar
      mtd: Add DiskOnChip G3 support · efa2ca73
      Robert Jarzmik authored
      
      
      Add support for DiskOnChip G3 chips. The support is quite
      limited yet :
       - no flash writes/erases are implemented
       - ECC fixes are not implemented
       - powerdown is not implemented
       - IPL handling is not yet done
      
      On the brighter side, the chip reading does work.
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      efa2ca73
  23. 09 Nov, 2009 1 commit
  24. 19 Sep, 2009 1 commit
  25. 12 Jun, 2009 1 commit
  26. 13 Mar, 2009 1 commit
  27. 08 Jan, 2009 1 commit
  28. 07 Aug, 2008 1 commit
  29. 01 Aug, 2008 1 commit
  30. 04 Jun, 2008 1 commit
  31. 25 Apr, 2008 1 commit
  32. 03 Aug, 2007 1 commit
  33. 28 Jun, 2007 1 commit
    • David Brownell's avatar
      [MTD] m25p80 handles more chips, uses JEDEC ids and small eraseblocks · fa0a8c71
      David Brownell authored
      
      
      Update chip ID tables in m25p80 to handle more SPI flash chips, matching
      datasheets.  All of these can use the same core operations and are newer
      chips that support the JEDEC "read id" instruction:
      
       - Atmel AT25 and AT26 (seven chips)
       - Spansion S25SL (five chips)
       - SST 25VF (four chips)
       - ST M25, M45 (five more chips)
       - Winbond W25X series (seven chips)
      
      That JEDEC instruction is now used, either to support a sanity check on the
      platform data holding board configuration data, or to determine chip type
      when it's not included in platform data.  In fact, boards that don't need a
      standard partition table may not need that platform data any more.
      
      For chips that support 4KiB erase units, use that smaller block size instead
      of the larger size (usually 64KiB); it's less wasteful.  (Tested on W25X80.)
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      fa0a8c71
  34. 02 May, 2007 1 commit
  35. 19 Apr, 2007 1 commit
  36. 17 Apr, 2007 1 commit