Hi Tudor, Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> 於 2024年10月4日 週五 下午5:58寫道: > > > > On 10/4/24 10:05 AM, Alvin Zhou wrote: > >>> + /* Read flash ID to make sure the switch was successful. */ > >>> + ret = spi_nor_read_id(nor, 4, 4, buf, SNOR_PROTO_8_8_8_DTR); > >> can we use nor->addr_nbytes for the second argument? Please test and > >> confirm. No need to resend for this, just confirm and I can amend when > >> applying. > > The following is the process of spi_nor_scan() > > int spi_nor_scan(...) > > { > > ...... > > ret = spi_nor_init_params(nor); > > ...... > > ret = spi_nor_setup(nor, hwcaps); > > ...... > > } > > First, within the spi_nor_parse_sfdp() function inside > > spi_nor_init_params(): nor->params->addr_nbytes is set based on the > > SFDP, while nor->addr_nbytes is not available. Therefore, the second > > argument cannot use nor->addr_nbytes but can use > > nor->params->addr_nbytes. Additionally, For Macronix Octal NOR Flash > > > nor->addr_nbytes is set in spi_nor_setup(). > spi_nor_set_octal_dtr() is called after spi_nor_setup(), thus you can > use nor->addr_nbytes. I apologize for the misunderstanding. Thanks for your clarification. So using nor->addr_nbytes as the second argument is not a problem. I have verified, thanks! > > > in Octal DDR mode, both the address and dummy cycles are fixed at 4 > > in READID, so setting the second and third argument to 4 is also valid. > > but we don't want magic numbers or states that are not tracked, so use > the parameters set > > > Moreover, nor->addr_nbytes is set within the spi_nor_setup() function. > > yep, use it then. Thanks, Alvin