1. 11 5月, 2020 3 次提交
  2. 25 3月, 2020 1 次提交
  3. 11 3月, 2020 2 次提交
  4. 28 6月, 2019 1 次提交
  5. 19 6月, 2019 1 次提交
  6. 18 4月, 2019 4 次提交
  7. 08 4月, 2019 9 次提交
  8. 05 2月, 2019 2 次提交
    • M
      mtd: rawnand: remove ->legacy.erase and single_erase() · 2d73f3d6
      Masahiro Yamada 提交于
      Now that the last user of this hook, denali.c, stopped using it,
      we can remove the erase hook from nand_legacy.
      
      I squashed single_erase() because only the difference between
      single_erase() and nand_erase_op() is the number of bit shifts.
      
      The status/ret conversion in nand_erase_nand() is unneeded since
      commit eb94555e ("mtd: nand: use usual return values for the
      ->erase() hook"). Cleaned it up now.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NBoris Brezillon <bbrezillon@kernel.org>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      2d73f3d6
    • B
      mtd: rawnand: Simplify the locking · 013e6292
      Boris Brezillon 提交于
      nand_get_device() was complex for apparently no good reason. Let's
      replace this locking scheme with 2 mutexes: one attached to the
      controller and another one attached to the chip.
      
      Every time the core calls nand_get_device(), it will first lock the
      chip and if the chip is not suspended, will then lock the controller.
      nand_release_device() will release both lock in the reverse order.
      
      nand_get_device() can sleep, just like the previous implementation,
      which means you should never call that from an atomic context.
      
      We also get rid of
      
      - the chip->state field, since all it was used for was flagging the
        chip as suspended. We replace it by a field called chip->suspended
        and directly set it from nand_suspend/resume()
      - the controller->wq and controller->active fields which are no longer
        needed since the new controller->lock (now a mutex) guarantees that
        all operations are serialized at the controller level
      - panic_nand_get_device() which would anyway be a no-op. Talking about
        panic write, I keep thinking the rawnand implementation is unsafe
        because there's not negotiation with the controller to know when it's
        actually done with it's previous operation. I don't intend to fix
        that here, but that's probably something we should look at, or maybe
        we should consider dropping the ->_panic_write() implementation
      
      Last important change to mention: we now return -EBUSY when someone
      tries to access a device that as been suspended, and propagate this
      error to the upper layer.
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      013e6292
  9. 07 12月, 2018 8 次提交
  10. 05 11月, 2018 1 次提交
  11. 03 10月, 2018 8 次提交