Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Mon, 4 May 2020 10:47:22 +0200: > On Mon, 4 May 2020 10:24:10 +0200 > Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote: > > > We already know that there are controllers not able to read the three > > copies of the parameter page in one go. The workaround was to first > > request the controller to assert command and address cycles on the > > NAND bus to trigger a parameter page read, and then do a simple read > > operation for each page. > > > > But there are also controllers which are not able to split the > > parameter page read between the command/address cycles and the actual > > data operation. > > > > Let's use a regular PARAMETER PAGE READ operation for the first > > iteration and use either a CHANGE READ COLUMN or a simple DATA READ > > operation for the following copies, depending on what the controller > > supports. The default behavior for non-exec-op compliant drivers > > remains the same: DATA READ. > > > > Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx> > > --- > > drivers/mtd/nand/raw/nand_onfi.c | 21 ++++++++++++++------- > > 1 file changed, 14 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/mtd/nand/raw/nand_onfi.c b/drivers/mtd/nand/raw/nand_onfi.c > > index e6ffbe8c9a0c..49cb04c02e9f 100644 > > --- a/drivers/mtd/nand/raw/nand_onfi.c > > +++ b/drivers/mtd/nand/raw/nand_onfi.c > > @@ -143,6 +143,7 @@ int nand_onfi_detect(struct nand_chip *chip) > > struct nand_memory_organization *memorg; > > struct nand_onfi_params *p = NULL, *pbuf; > > struct onfi_params *onfi; > > + bool use_datain = false; > > int onfi_version = 0; > > char id[4]; > > int i, ret, val; > > @@ -160,15 +161,21 @@ int nand_onfi_detect(struct nand_chip *chip) > > if (!pbuf) > > return -ENOMEM; > > > > - ret = nand_read_param_page_op(chip, 0, NULL, 0); > > - if (ret) { > > - ret = 0; > > - goto free_onfi_param_page; > > - } > > + if (!nand_has_exec_op(chip) || > > + (nand_read_data_op(chip, &pbuf[0], sizeof(*pbuf), true, true) == 0)) > > Just nitpicking, but isn't checkpatch complaining about unneeded parens? Mmmh no, where? I think there is no need for (!nand_has_exec_op(chip)) if this is what you mean? Checkpatch --strict does not produce a warning here. > Any reason you didn't use > > !nand_read_data_op(chip, &pbuf[0], sizeof(*pbuf), true, true) I usually write conditions this way, but here I read it like "if not nand_read_data_op is supported" which means the opposite of what it is doing. Instead, I read the "== 0" as "I expect it to return 0 and it means it is okay". Maybe its purely personal :) > > here? > > The rest looks good, > > Reviewed-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/