1. 21 3月, 2019 1 次提交
    • G
      mtd: rawnand: Mark expected switch fall-throughs · 64f1da10
      Gustavo A. R. Silva 提交于
      In preparation to enabling -Wimplicit-fallthrough, mark switch
      cases where we are expecting to fall through.
      
      This patch fixes the following warning:
      
      drivers/mtd/nand/raw/diskonchip.c: In function ‘doc_probe’:
      ./include/linux/printk.h:303:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
        printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/mtd/nand/raw/diskonchip.c:1479:4: note: in expansion of macro ‘pr_err’
          pr_err("DiskOnChip Millennium Plus 32MB is not supported, ignoring.\n");
          ^~~~~~
      drivers/mtd/nand/raw/diskonchip.c:1480:3: note: here
         default:
         ^~~~~~~
      drivers/mtd/nand/raw/nandsim.c: In function ‘ns_init_module’:
      drivers/mtd/nand/raw/nandsim.c:2254:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
          chip->bbt_options |= NAND_BBT_NO_OOB;
      drivers/mtd/nand/raw/nandsim.c:2255:2: note: here
        case 1:
        ^~~~
      drivers/mtd/nand/raw/nuc900_nand.c: In function ‘nuc900_nand_command_lp’:
      ./arch/x86/include/asm/io.h:91:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
       #define __raw_writel __writel
      drivers/mtd/nand/raw/nuc900_nand.c:52:2: note: in expansion of macro ‘__raw_writel’
        __raw_writel((val), (dev)->reg + REG_SMCMD)
        ^~~~~~~~~~~~
      drivers/mtd/nand/raw/nuc900_nand.c:196:3: note: in expansion of macro ‘write_cmd_reg’
         write_cmd_reg(nand, NAND_CMD_READSTART);
         ^~~~~~~~~~~~~
      drivers/mtd/nand/raw/nuc900_nand.c:197:2: note: here
        default:
        ^~~~~~~
      drivers/mtd/nand/raw/omap_elm.c: In function ‘elm_context_restore’:
      drivers/mtd/nand/raw/omap_elm.c:512:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
          elm_write_reg(info, ELM_SYNDROME_FRAGMENT_4 + offset,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            regs->elm_syndrome_fragment_4[i]);
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/mtd/nand/raw/omap_elm.c:514:3: note: here
         case BCH8_ECC:
         ^~~~
      drivers/mtd/nand/raw/omap_elm.c:517:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
          elm_write_reg(info, ELM_SYNDROME_FRAGMENT_2 + offset,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            regs->elm_syndrome_fragment_2[i]);
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/mtd/nand/raw/omap_elm.c:519:3: note: here
         case BCH4_ECC:
         ^~~~
      drivers/mtd/nand/raw/omap_elm.c: In function ‘elm_context_save’:
      drivers/mtd/nand/raw/omap_elm.c:466:37: warning: this statement may fall through [-Wimplicit-fallthrough=]
          regs->elm_syndrome_fragment_4[i] = elm_read_reg(info,
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
            ELM_SYNDROME_FRAGMENT_4 + offset);
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/mtd/nand/raw/omap_elm.c:468:3: note: here
         case BCH8_ECC:
         ^~~~
      drivers/mtd/nand/raw/omap_elm.c:471:37: warning: this statement may fall through [-Wimplicit-fallthrough=]
          regs->elm_syndrome_fragment_2[i] = elm_read_reg(info,
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
            ELM_SYNDROME_FRAGMENT_2 + offset);
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/mtd/nand/raw/omap_elm.c:473:3: note: here
         case BCH4_ECC:
         ^~~~
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      This patch is part of the ongoing efforts to enabling
      -Wimplicit-fallthrough.
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      64f1da10
  2. 07 12月, 2018 1 次提交
  3. 03 10月, 2018 18 次提交
  4. 18 7月, 2018 1 次提交
  5. 29 4月, 2018 1 次提交
  6. 25 4月, 2018 2 次提交
    • T
      mtd: rawnand: diskonchip: Allocate rs control per instance · 964dfce9
      Thomas Gleixner 提交于
      The reed solomon library is moving the on stack decoder buffers into the rs
      control structure. That would break the DoC driver because multiple
      instances share the same control structure and can operate in parallel. At
      least in theory....
      
      Instantiate a rs control instance per DoC device to avoid that. The per
      instance buffer is fine as the operation on a single DoC instance is
      serialized by the MTD/NAND core.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Andrew Morton <akpm@linuxfoundation.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Alasdair Kergon <agk@redhat.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      964dfce9
    • T
      rslib: Split rs control struct · 21633981
      Thomas Gleixner 提交于
      The decoder library uses variable length arrays on stack. To get rid of
      them it would be simple to allocate fixed length arrays on stack, but those
      might become rather large. The other solution is to allocate the buffers in
      the rs control structure, but this cannot be done as long as the structure
      can be shared by several users. Sharing is desired because the RS polynom
      tables are large and initialization is time consuming.
      
      To solve this split the codec information out of the control structure and
      have a pointer to a shared codec in it. Instantiate the control structure
      for each user, create a new codec if no shareable is avaiable yet.  Adjust
      all affected usage sites to the new scheme.
      
      This allows to add per instance decoder buffers to the control structure
      later on.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Kernel Hardening <kernel-hardening@lists.openwall.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Andrew Morton <akpm@linuxfoundation.org>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Alasdair Kergon <agk@redhat.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      21633981
  7. 15 3月, 2018 1 次提交
  8. 16 2月, 2018 2 次提交
  9. 14 12月, 2017 1 次提交
  10. 18 9月, 2017 1 次提交
  11. 13 8月, 2017 1 次提交
  12. 06 5月, 2016 1 次提交
  13. 11 3月, 2016 1 次提交
    • A
      mtd: nand: don't select chip in nand_chip's block_bad op · 9f3e0429
      Archit Taneja 提交于
      One of the arguments passed to struct nand_chip's block_bad op is
      'getchip', which, if true, is supposed to get and select the nand device,
      and later unselect and release the device.
      
      This op is intended to be replaceable by drivers. The drivers shouldn't
      be responsible for selecting/unselecting chip. Like other ops, the chip
      should already be selected before the block_bad op is called.
      
      Remove the getchip argument from the block_bad op and
      nand_block_checkbad. Move the chip selection to nand_block_isbad, since it
      is the only caller to nand_block_checkbad which requires chip selection.
      
      Modify nand_block_bad (the default function for the op) such that it
      doesn't select the chip.
      
      Remove the getchip argument from the bad_block funcs in cafe_nand,
      diskonchip and docg4 drivers.
      Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      9f3e0429
  14. 08 1月, 2016 1 次提交
  15. 07 1月, 2016 1 次提交
  16. 19 12月, 2015 2 次提交
  17. 09 12月, 2015 1 次提交
  18. 11 8月, 2015 1 次提交
  19. 17 6月, 2015 1 次提交
    • B
      mtd: diskonchip: remove two-phase partitioning / registration · 6a7c7334
      Brian Norris 提交于
      It is a Bad Idea (TM) to call mtd_device_register() or
      mtd_device_parse_register() twice on the same master MTD. Among other
      things, it makes partition overrides (e.g., cmdlinepart) much more
      difficult.
      
      Since commit 727dc612 ("mtd: part: Create the master device node
      when partitioned"), we now have a config option that accomplishes the
      same purpose as the double-registration done in diskonchip.c -- it
      forces the master MTD to *always* be registered, while partitions may
      optionally show up in addition. Eventually, we might like to make
      CONFIG_MTD_PARTITIONED_MASTER into the default, but this could be
      disruptive to user-space expectations of MTD numbering, so we'll take
      that slowly.
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Alexander Shiyan <shc_work@mail.ru>
      6a7c7334
  20. 07 5月, 2015 1 次提交
    • B
      mtd: diskonchip: don't call nand_scan_bbt() directly · d24fe0c3
      Brian Norris 提交于
      The diskonchip driver almost uses the default nand_base hooks as-is,
      except that it provides custom on-flash BBT descriptors and avoids using
      factory-marked bad blockers.
      
      So let's refactor the BBT initialization code into a private 'late_init'
      hook which handles all the private details. Note the usage of
      NAND_SKIP_BBTSCAN, which allows us to defer the BBT scan until we've
      prepared everything.
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      d24fe0c3