NAND parameter page read fails with bitflip and no column change support

[Steven Seeger]

Hello list.

I have an interesting board with 8GB of NAND, and the first of 8 chips has a bitflip in the first ONFI 256 bytes of the ONFI parameter page. My driver did not support column change operations, and this worked fine with linux 5.x kernels. I noticed this problem with a 6.6 kernel, and the fix was to add column change support to my driver. Without it, the NAND layer always reads the first 256 bytes of the parameter page. As my hardware is an FPGA that abstracts some of the direct NAND access away, and ECC Is done on-die, the driver is a bit of a hybrid between the newer exec operation API and providing functions like nand_read_page, nand_read_page_raw, etc. So the parameter page read upon module load uses the data in instructions in the exec command, while page and OOB reads and writes are done through the driver-supplied functions.

Adding support for column change operations fixed this issue, but it seems that this support should not be necessary. It  didn't use to work that way.

I had reached out to Miquel privately with this issue, only due to the desire to help inform maintainers of the issue. I was too busy at the time to join the list and write up something more formal. Miquel provided a small patch for me that did not work at the time, and then I lost access to the board for a while. Now I have a little time and a board, so I am here to report the issue and make it public.

I am fine continuing my work with my driver that supports column change operations, but also happy to use a previous commit of it to do any additional testing with any patch provided as long as I have a board.

>From my original email to Miquel:

Your commit 9f820fc0651c32f8dde26b8e3ad93e1b9fdb62c4 I think has a small bug.

In rawnand_check_data_only_read_support(), you call nand_read_data_op() with a NULL buffer, which causes nand_read_data_op() to return -EINVAL, therefore the value for data_only_read is never set.

Apologies to the people on CC for sending this a couple of times due to errors.

Thanks,
Steven