On Tue, 22 Jan 2019 00:57:43 +0900 Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote: > > Maybe, is the following better? Sounds good, even if the original commit message was fine too. I was just pointing out that nand_scan() should, when possible, be passed the real number of CS lines connected to the chip instead of the max number of CS lines supported by the controller. > > > ------------------>8----------------------- > nand_scan_ident() iterates over maxchips to find as many homogeneous > chips as possible. > > Since commit 2d472aba15ff ("mtd: nand: document the NAND controller/NAND > chip DT representation"), new drivers should pass in the exact number of > CS lines instead of possible max, but old platforms may still rely on > nand_scan_ident() to detect the actual number of connected CS lines. > > In that case, this loop bails out when manufacturer or device ID > unmatches. The reason of unmatch is most likely no chip is connected > to that CS line. If so, nand_reset() should already have failed, > and the following nand_readid_op() is pointless. > > Before ->exec_op hook was introduced, drivers had no way to tell > the failure of NAND_CMD_RESET to the framework because the legacy > ->cmdfunc() has void return type. Now drivers implementing ->exec_op > hook can return the error code. You can save nand_readid_op() by > checking the return value of nand_reset(). The return value of > nand_readid_op() should be checked as well. If it fails, probably > id[0] and id[1] are undefined values. > > Just for consistency, it should be sensible to check the return > code in nand_do_write_oob() as well. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/