linux-kernel - Re: [PATCH] staging:mt29f_spinand: MT29F2G failing as only 16-bit arguments and variables used for addressing.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Aug 2018 15:05:51 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Jheng-Jhong Wu <goodwater.wu@...il.com>,
        Palle Christensen <palle.christensen@...rosemi.com>
Cc:     devel@...verdev.osuosl.org,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Palle Christensen <palle.christensen@...rosemi.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Arun Nagendran <arunrasppi@...il.com>,
        Miquel Raynal <miquel.raynal@...tlin.com>
Subject: Re: [PATCH] staging:mt29f_spinand: MT29F2G failing as only 16-bit
 arguments and variables used for addressing.

On Wed, Aug 01, 2018 at 11:24:19AM +0800, Jheng-Jhong Wu wrote:
> For NAND flash chips with more than 1Gbit (e.g. MT29F2G) more than 16 bits
> are necessary to address the correct page. The driver sets the address for
> more than 16 bits, but it uses 16-bit arguments and variables (these are
> page_id, block_id, row) to do address operations. Obviously, these
> arguments and variables cannot deal with more than 16-bit address.
> 
> Signed-off-by: Jheng-Jhong Wu <goodwater.wu@...il.com>

This seems reasonable...  It would be needed to make commit 6efb21d6d0e7
("staging:mt29f_spinand: MT29F2G failing as only 16 bits used for
addressing.") work.  It also fixes a static checker warning.

My only concern is that the mtd/nand code seems to use -1 as a magical
page_id.  For example:


  2069  /**
  2070   * nand_exit_status_op - Exit a STATUS operation
  2071   * @chip: The NAND chip
  2072   *
  2073   * This function sends a READ0 command to cancel the effect of the STATUS
  2074   * command to avoid reading only the status until a new read command is sent.
  2075   *
  2076   * This function does not select/unselect the CS line.
  2077   *
  2078   * Returns 0 on success, a negative error code otherwise.
  2079   */
  2080  int nand_exit_status_op(struct nand_chip *chip)
  2081  {
  2082          struct mtd_info *mtd = nand_to_mtd(chip);
  2083  
  2084          if (chip->exec_op) {
  2085                  struct nand_op_instr instrs[] = {
  2086                          NAND_OP_CMD(NAND_CMD_READ0, 0),
  2087                  };
  2088                  struct nand_operation op = NAND_OPERATION(instrs);
  2089  
  2090                  return nand_exec_op(chip, &op);
  2091          }
  2092  
  2093          chip->cmdfunc(mtd, NAND_CMD_READ0, -1, -1);
                                   ^^^^^^^^^^^^^^      ^^
  2094  
  2095          return 0;
  2096  }
  2097  EXPORT_SYMBOL_GPL(nand_exit_status_op);

I'm not sure if this affect spinand_read_page() etc.

regards,
dan carpenter