Hi Michal, On 27/08/2026 at 13:10:13 +02, Michal Simek <[email protected]> wrote:
> On 7/2/26 15:08, Bastien Curutchet wrote: >> From: "Miquel Raynal (DAVE.eu)" <[email protected]> >> If there is no indication about 16b buswidth, no need to fail the >> probe, >> just assume it is the (very standard) 8b case. >> Signed-off-by: Miquel Raynal (DAVE.eu) <[email protected]> >> Signed-off-by: Bastien Curutchet (DAVE.eu) <[email protected]> >> --- >> drivers/mtd/nand/raw/zynq_nand.c | 6 ------ >> 1 file changed, 6 deletions(-) >> diff --git a/drivers/mtd/nand/raw/zynq_nand.c >> b/drivers/mtd/nand/raw/zynq_nand.c >> index 54c25563072..be080cbb074 100644 >> --- a/drivers/mtd/nand/raw/zynq_nand.c >> +++ b/drivers/mtd/nand/raw/zynq_nand.c >> @@ -1134,12 +1134,6 @@ static int zynq_nand_probe(struct udevice *dev) >> nand_chip->write_buf = zynq_nand_write_buf; >> is_16bit_bw = zynq_nand_check_is_16bit_bw_flash(); >> - if (is_16bit_bw == NAND_BW_UNKNOWN) { >> - printf("%s: Unable detect NAND based on MIO settings\n", >> - __func__); >> - return -EINVAL; >> - } >> - > > But why is there a failure in the first place? Honestly, I no longer remember what kind of failure I was facing exactly, but there are chances that the function checking for 16-bit buswidth is not super robust and may return UNKNOWN which fails the probe for no good reason. The nand-bus-width DT property exists since 2012 and the default (if not provided) has always been to fallback to 8, hence my proposal. Cheers, Miquèl
