1. 03 8月, 2017 1 次提交
  2. 23 6月, 2017 1 次提交
    • R
      mtd: partitions: add support for partition parsers · 1a0915be
      Rafał Miłecki 提交于
      Some devices have partitions that are kind of containers with extra
      subpartitions / volumes instead of e.g. a simple filesystem data. To
      support such cases we need to first create normal flash device
      partitions and then take care of these special ones.
      
      It's very common case for home routers. Depending on the vendor there
      are formats like TRX, Seama, TP-Link, WRGG & more. All of them are used
      to embed few partitions into a single one / single firmware file.
      
      Ideally all vendors would use some well documented / standardized format
      like UBI (and some probably start doing so), but there are still
      countless devices on the market using these poor vendor specific
      formats.
      
      This patch extends MTD subsystem by allowing to specify list of parsers
      that should be tried for a given partition. Supporting such poor formats
      is highly unlikely to be the top priority so these changes try to
      minimize maintenance cost to the minimum. It reuses existing code for
      these new parsers and just adds a one property and one new function.
      
      This implementation requires setting partition parsers in a flash
      parser. A proper change of bcm47xxpart will follow and in the future we
      will hopefully also find a solution for doing it with ofpart
      ("fixed-partitions").
      Signed-off-by: NRafał Miłecki <rafal@milecki.pl>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      1a0915be
  3. 10 6月, 2017 2 次提交
    • M
      mtd: nand: add a shorthand to generate nand_ecc_caps structure · a03c6017
      Masahiro Yamada 提交于
      struct nand_ecc_caps was designed as flexible as possible to support
      multiple stepsizes (like sunxi_nand.c).
      
      So, we need to write multiple arrays even for the simplest case.
      I guess many controllers support a single stepsize, so here is a
      shorthand macro for the case.
      
      It allows to describe like ...
      
      NAND_ECC_CAPS_SINGLE(denali_pci_ecc_caps, denali_calc_ecc_bytes, 512, 8, 15);
      
      ... instead of
      
      static const int denali_pci_ecc_strengths[] = {8, 15};
      static const struct nand_ecc_step_info denali_pci_ecc_stepinfo = {
              .stepsize = 512,
              .strengths = denali_pci_ecc_strengths,
              .nstrengths = ARRAY_SIZE(denali_pci_ecc_strengths),
      };
      static const struct nand_ecc_caps denali_pci_ecc_caps = {
              .stepinfos = &denali_pci_ecc_stepinfo,
              .nstepinfos = 1,
              .calc_ecc_bytes = denali_calc_ecc_bytes,
      };
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      a03c6017
    • M
      mtd: nand: add generic helpers to check, match, maximize ECC settings · 2c8f8afa
      Masahiro Yamada 提交于
      Driver are responsible for setting up ECC parameters correctly.
      Those include:
        - Check if ECC parameters specified (usually by DT) are valid
        - Meet the chip's ECC requirement
        - Maximize ECC strength if NAND_ECC_MAXIMIZE flag is set
      
      The logic can be generalized by factoring out common code.
      
      This commit adds 3 helpers to the NAND framework:
      nand_check_ecc_caps - Check if preset step_size and strength are valid
      nand_match_ecc_req - Match the chip's requirement
      nand_maximize_ecc - Maximize the ECC strength
      
      To use the helpers above, a driver needs to provide:
        - Data array of supported ECC step size and strength
        - A hook that calculates ECC bytes from the combination of
          step_size and strength.
      
      By using those helpers, code duplication among drivers will be
      reduced.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      2c8f8afa
  4. 01 6月, 2017 3 次提交
    • B
      mtd: nand: Drop the ->errstat() hook · 7d135bcc
      Boris Brezillon 提交于
      The ->errstat() hook is no longer implemented NAND controller drivers.
      Get rid of it before someone starts abusing it.
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      7d135bcc
    • B
      mtd: nand: Pass the CS line to ->setup_data_interface() · 104e442a
      Boris Brezillon 提交于
      Some NAND controllers can assign different NAND timings to different
      CS lines. Pass the CS line information to ->setup_data_interface() so
      that the NAND controller driver knows which CS line is concerned by
      the setup_data_interface() request.
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      104e442a
    • T
      mtd: nand: add support for Micron on-die ECC · 9748e1d8
      Thomas Petazzoni 提交于
      Now that the core NAND subsystem has support for on-die ECC, this commit
      brings the necessary code to support on-die ECC on Micron NANDs.
      
      In micron_nand_init(), we detect if the Micron NAND chip supports on-die
      ECC mode, by checking a number of conditions:
      
       - It must be an ONFI NAND
       - It must be a SLC NAND
      
       - Enabling *and* disabling on-die ECC must work
      
       - The on-die ECC must be correcting 4 bits per 512 bytes of data. Some
         Micron NAND chips have an on-die ECC able to correct 8 bits per 512
         bytes of data, but they work slightly differently and therefore we
         don't support them in this patch.
      
      Then, if the on-die ECC cannot be disabled (some Micron NAND have on-die
      ECC forcefully enabled), we bail out, as we don't support such
      NANDs. Indeed, the implementation of raw_read()/raw_write() make the
      assumption that on-die ECC can be disabled. Support for Micron NANDs
      with on-die ECC forcefully enabled can easily be added, but in the
      absence of such HW for testing, we preferred to simply bail out.
      
      If the on-die ECC is supported, and requested in the Device Tree, then
      it is indeed enabled, by using custom implementations of the
      ->read_page(), ->read_page_raw(), ->write_page() and ->write_page_raw()
      operation to properly handle the on-die ECC.
      
      In the non-raw functions, we need to enable the internal ECC engine
      before issuing the NAND_CMD_READ0 or NAND_CMD_SEQIN commands, which is
      why we set the NAND_ECC_CUSTOM_PAGE_ACCESS option at initialization
      time (it asks the NAND core to let the NAND driver issue those
      commands).
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      9748e1d8
  5. 30 5月, 2017 1 次提交
  6. 16 5月, 2017 4 次提交
    • M
      mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings · b6f6c294
      Mauro Carvalho Chehab 提交于
      ./drivers/mtd/nand/nand_bbt.c:1: warning: no structured comments found
      ./include/linux/mtd/nand.h:785: ERROR: Unexpected indentation.
      ./drivers/mtd/nand/nand_base.c:449: WARNING: Definition list ends without a blank line; unexpected unindent.
      ./drivers/mtd/nand/nand_base.c:1161: ERROR: Unexpected indentation.
      ./drivers/mtd/nand/nand_base.c:1162: WARNING: Block quote ends without a blank line; unexpected unindent.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      b6f6c294
    • C
      mtd: spi-nor: introduce Octo SPI protocols · fe488a5e
      Cyrille Pitchen 提交于
      This patch starts adding support to Octo SPI protocols (SPI x-y-8).
      
      Op codes for Fast Read and/or Page Program operations using Octo SPI
      protocols are not known yet (no JEDEC specification has defined them yet)
      but we'd rather introduce the Octo SPI protocols now so it's done as it
      should be.
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
      fe488a5e
    • C
      mtd: spi-nor: introduce Double Transfer Rate (DTR) SPI protocols · 15f55331
      Cyrille Pitchen 提交于
      This patch introduces support to Double Transfer Rate (DTR) SPI protocols.
      DTR is used only for Fast Read operations.
      
      According to manufacturer datasheets, whatever the number of I/O lines
      used during instruction (x) and address/mode/dummy (y) clock cycles, DTR
      is used only during data (z) clock cycles of SPI x-y-z protocols.
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
      15f55331
    • C
      mtd: spi-nor: introduce SPI 1-2-2 and SPI 1-4-4 protocols · cfc5604c
      Cyrille Pitchen 提交于
      This patch changes the prototype of spi_nor_scan(): its 3rd parameter
      is replaced by a 'struct spi_nor_hwcaps' pointer, which tells the spi-nor
      framework about the actual hardware capabilities supported by the SPI
      controller and its driver.
      
      Besides, this patch also introduces a new 'struct spi_nor_flash_parameter'
      telling the spi-nor framework about the hardware capabilities supported by
      the SPI flash memory and the associated settings required to use those
      hardware caps.
      
      Then, to improve the readability of spi_nor_scan(), the discovery of the
      memory settings and the memory initialization are now split into two
      dedicated functions.
      
      1 - spi_nor_init_params()
      
      The spi_nor_init_params() function is responsible for initializing the
      'struct spi_nor_flash_parameter'. Currently this structure is filled with
      legacy values but further patches will allow to override some parameter
      values dynamically, for instance by reading the JESD216 Serial Flash
      Discoverable Parameter (SFDP) tables from the SPI memory.
      The spi_nor_init_params() function only deals with the hardware
      capabilities of the SPI flash memory: especially it doesn't care about
      the hardware capabilities supported by the SPI controller.
      
      2 - spi_nor_setup()
      
      The second function is called once the 'struct spi_nor_flash_parameter'
      has been initialized by spi_nor_init_params().
      With both 'struct spi_nor_flash_parameter' and 'struct spi_nor_hwcaps',
      the new argument of spi_nor_scan(), spi_nor_setup() computes the best
      match between hardware caps supported by both the (Q)SPI memory and
      controller hence selecting the relevant settings for (Fast) Read and Page
      Program operations.
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
      cfc5604c
  7. 15 5月, 2017 2 次提交
    • T
      mtd: nand: export nand_{read,write}_page_raw() · cc0f51ec
      Thomas Petazzoni 提交于
      The nand_read_page_raw() and nand_write_page_raw() functions might be
      re-used by vendor-specific implementations of the read_page/write_page
      functions. Instead of having vendor-specific code duplicate this code,
      it is much better to export those functions and allow them to be
      re-used.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      cc0f51ec
    • T
      mtd: nand: add core support for on-die ECC · 785818fa
      Thomas Petazzoni 提交于
      A number of NAND flashes have a capability called "on-die ECC" where the
      NAND chip itself is capable of detecting and correcting errors.
      
      Linux already has support for using the ECC implementation of the NAND
      controller, or a software based ECC implementation, but not for using
      the ECC implementation of the NAND controller. However, such an
      implementation is sometimes useful in situations where the NAND
      controller provides ECC algorithms that are not strong enough for the
      NAND chip used on the system. A typical case is a NAND chip that
      requires a 4-bit ECC, while the NAND controller only provides a 1-bit
      ECC algorithm.
      
      This commit introduces the support for the NAND_ECC_ON_DIE ECC mode:
      
       - Parsing of the "on-die" value for the "nand-ecc-mode" Device Tree
         property
      
       - Handling NAND_ECC_ON_DIE case in nand_scan_tail(). The idea is that
         the vendor specific code for the NAND chip must implement
         ->read_page() and ->write_page(). It may optionally provide its own
         ->read_page_raw() and ->write_page_raw() as well. For OOB operation,
         we assume the standard operations are good enough, but they can be
         overridden by the vendor specific code if needed.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      785818fa
  8. 25 4月, 2017 3 次提交
  9. 21 4月, 2017 1 次提交
    • J
      mtd: Convert to dynamically allocated bdi infrastructure · fa06052d
      Jan Kara 提交于
      MTD already allocates backing_dev_info dynamically. Convert it to use
      generic infrastructure for this including proper refcounting. We drop
      mtd->backing_dev_info as its only use was to pass mtd_bdi pointer from
      one file into another and if we wanted to keep that in a clean way, we'd
      have to make mtd hold and drop bdi reference as needed which seems
      pointless for passing one global pointer...
      
      CC: David Woodhouse <dwmw2@infradead.org>
      CC: Brian Norris <computersforpeace@gmail.com>
      CC: linux-mtd@lists.infradead.org
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      fa06052d
  10. 20 4月, 2017 1 次提交
  11. 09 3月, 2017 10 次提交
  12. 28 2月, 2017 1 次提交
  13. 11 2月, 2017 1 次提交
  14. 10 2月, 2017 3 次提交
  15. 09 2月, 2017 2 次提交
  16. 06 2月, 2017 1 次提交
  17. 30 1月, 2017 2 次提交
  18. 19 11月, 2016 1 次提交