1. 05 9月, 2018 1 次提交
  2. 01 8月, 2018 1 次提交
  3. 31 7月, 2018 5 次提交
    • M
      mtd: rawnand: allocate model parameter dynamically · 2023f1fa
      Miquel Raynal 提交于
      Thanks to the migration of all drivers to use nand_scan() and the
      related nand_controller_ops, we can now allocate data during the
      detection phase. Let's do it first for the NAND model parameter which
      is allocated in nand_detect().
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      2023f1fa
    • M
      mtd: rawnand: do not export nand_scan_[ident|tail]() anymore · 98732da1
      Miquel Raynal 提交于
      Both nand_scan_ident() and nand_scan_tail() helpers used to be called
      directly from controller drivers that needed to tweak some ECC-related
      parameters before nand_scan_tail(). This separation prevented dynamic
      allocations during the phase of NAND identification, which was
      inconvenient.
      
      All controller drivers have been moved to use nand_scan(), in
      conjunction with the chip->ecc.[attach|detach]_chip() hooks that
      actually do the required tweaking sequence between both ident/tail
      calls, allowing programmers to use dynamic allocation as they need all
      across the scanning sequence.
      
      Declare nand_scan_[ident|tail]() statically now.
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      98732da1
    • M
      mtd: rawnand: add hooks that may be called during nand_scan() · 05b54c7b
      Miquel Raynal 提交于
      In order to remove the limitation that forbids dynamic allocation in
      nand_scan_ident(), we must create a path that will be the same for all
      controller drivers. The idea is to use nand_scan() instead of the widely
      used nand_scan_ident()/nand_scan_tail() couple. In order to achieve
      this, controller drivers will need to adjust some parameters between
      these two functions depending on the NAND chip wired on them.
      
      This takes the form of two new hooks (->{attach,detach}_chip()) that are
      placed in a new nand_controller_ops structure, which is then attached
      to the nand_controller object at driver initialization time.
      ->attach_chip() is called between nand_scan_ident() and
      nand_scan_tail(), and ->detach_chip() is called in the error path of
      nand_scan() and in nand_cleanup().
      
      Note that some NAND controller drivers don't have a dedicated
      nand_controller object and instead rely on the default/dummy one
      embedded in nand_chip. If you're in this case and still want to
      initialize the controller ops, you'll have to manipulate
      chip->dummy_controller directly.
      
      Last but not least, it's worth mentioning that we plan to move some of
      the controller related hooks placed in nand_chip into
      nand_controller_ops to make the separation between NAND chip and NAND
      controller methods clearer.
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Acked-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      05b54c7b
    • M
      mtd: rawnand: better name for the controller structure · 7da45139
      Miquel Raynal 提交于
      In the raw NAND core, a NAND chip is described by a nand_chip structure,
      while a NAND controller is described with a nand_hw_control structure
      which is not very meaningful.
      
      Rename this structure nand_controller.
      
      As the structure gets renamed, it is logical to also rename the core
      function initializing it from nand_hw_control_init() to
      nand_controller_init().
      
      Lastly, the 'hwcontrol' entry of the nand_chip structure is not
      meaningful neither while it has the role of fallback when no controller
      structure is provided by the driver (the controller driver is dumb and
      can only control a single chip). Thus, it is renamed dummy_controller.
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Acked-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      7da45139
    • M
      mtd: rawnand: make subop helpers return unsigned values · 760c435e
      Miquel Raynal 提交于
      A report from Colin Ian King pointed a CoverityScan issue where error
      values on these helpers where not checked in the drivers. These
      helpers can error out only in case of a software bug in driver code,
      not because of a runtime/hardware error. Hence, let's WARN_ON() in this
      case and return 0 which is harmless anyway.
      
      Fixes: 8878b126 ("mtd: nand: add ->exec_op() implementation")
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Reviewed-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      760c435e
  4. 20 7月, 2018 1 次提交
  5. 18 7月, 2018 8 次提交
  6. 02 7月, 2018 4 次提交
  7. 15 5月, 2018 1 次提交
  8. 09 5月, 2018 1 次提交
    • M
      mtd: rawnand.h: use nested union kernel-doc markups · a6766880
      Mauro Carvalho Chehab 提交于
      Gets rid of those warnings and better document the parameters.
      
        ./include/linux/mtd/rawnand.h:752: warning: Function parameter or member 'timings.sdr' not described in 'nand_data_interface'
        ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf' not described in 'nand_op_data_instr'
        ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.in' not described in 'nand_op_data_instr'
        ./include/linux/mtd/rawnand.h:817: warning: Function parameter or member 'buf.out' not described in 'nand_op_data_instr'
        ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx' not described in 'nand_op_instr'
        ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.cmd' not described in 'nand_op_instr'
        ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_instr'
        ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.data' not described in 'nand_op_instr'
        ./include/linux/mtd/rawnand.h:863: warning: Function parameter or member 'ctx.waitrdy' not described in 'nand_op_instr'
        ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx' not described in 'nand_op_parser_pattern_elem'
        ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.addr' not described in 'nand_op_parser_pattern_elem'
        ./include/linux/mtd/rawnand.h:1010: warning: Function parameter or member 'ctx.data' not described in 'nand_op_parser_pattern_elem'
        ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.desc' not described in 'nand_chip'
        ./include/linux/mtd/rawnand.h:1313: warning: Function parameter or member 'manufacturer.priv' not described in 'nand_chip'
      
        ./include/linux/mtd/rawnand.h:848: WARNING: Unexpected indentation.
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      a6766880
  9. 29 4月, 2018 1 次提交
  10. 20 3月, 2018 7 次提交
  11. 20 1月, 2018 1 次提交
  12. 16 12月, 2017 1 次提交
    • M
      mtd: nand: add ->exec_op() implementation · 8878b126
      Miquel Raynal 提交于
      Introduce a new interface to instruct NAND controllers to send specific
      NAND operations. The new interface takes the form of a single method
      called ->exec_op(). This method is designed to replace ->cmd_ctrl(),
      ->cmdfunc() and ->read/write_byte/word/buf() hooks.
      
      ->exec_op() is passed a set of instructions describing the operation
      to execute. Each instruction has a type (ADDR, CMD, DATA, WAITRDY)
      and delay. The delay is here to help simple controllers wait enough
      time between each instruction, advanced controllers with integrated
      timings control can ignore these delays.
      
      Controllers that natively support complex operations (operations
      formed of several instructions) can use the NAND op parser
      infrastructure. This infrastructure allows controller drivers to
      describe the sequence of instructions they support (called
      nand_op_pattern) and a hook for each of these supported sequences. The
      core then tries to find the best match for a given NAND operation, and
      calls the associated hook.
      
      Various other helpers are also added to ease NAND controller drivers
      writing.
      
      This new interface should ease support of vendor specific operations
      in that NAND manufacturer drivers now have a way to check if the
      controller they are connected to supports a specific operation, and
      complain or refuse to probe the NAND chip when that's not the case.
      Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      8878b126
  13. 14 12月, 2017 5 次提交
  14. 18 9月, 2017 1 次提交
  15. 30 8月, 2017 1 次提交
  16. 13 8月, 2017 1 次提交