On 11/2/20 2:11 PM, Johan Jonker wrote: > Hi, > > On 11/2/20 2:07 PM, Miquel Raynal wrote: >> Hi Johan, Yifeng >> >> Johan Jonker <jbx6244@xxxxxxxxx> wrote on Mon, 2 Nov 2020 13:57:56 >> +0100: >> >>> Hi Yifeng, >>> >>> Don't poke with "ecc->bytes" ones it is set in rk_nfc_ecc_init(). It >>> will not be noted by the MTD frame work or userspace. I think there's >>> currently no way to let the user know that a different ECC must be used. >>> Neither can the user set ECC on the fly. >>> >>> Example R/W flow: >>> >>> nand_select_target() >>> chip->ecc.write_page_raw() >>> chip->ecc.write_page() >>> >>> [..] >>> >>> chip->ecc.read_page_raw() >>> chip->ecc.read_page() >>> nand_deselect_target() >>> >>> A write/read with: >>> >>> rk_nfc_read_page_hwecc() >>> rk_nfc_write_page_hwecc() >>> >>> or >>> >>> rk_nfc_read_page_raw() >>> rk_nfc_write_page_raw() >>> >>> must end up with the same result. If we can't archive that, then we >>> shouldn't offer RAW mode to the user for now. If Miquel agrees you >>> should just get the driver ready now without these 2 functions and round >>> things up. >> >> What about just not supporting the BootROM area if it was marked >> "reserved" by the BRom in the DT? > > Should we just fill the buffers with '0xff' for boot blocks? (part 2) ;) My fault.... Better use: if ((chip->options & NAND_IS_BOOT_MEDIUM) && (page < (pages_per_blk * rknand->boot_blks))) { return -EIO; } > >> >> Raw accessors is really a nice and basic feature that I would like to >> have in every new driver. >> >> Thanks, >> Miquèl >> >