On Thu, 17 Jan 2019 22:33:01 +0100 Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Mon, Jan 14, 2019 at 9:51 AM Boris Brezillon <bbrezillon@xxxxxxxxxx> wrote: > > > Not related to this patch, but I think we're missing a nand_reset() > > call in the ->resume() path. Without it FSMC timings might be wrong > > after a suspend if they're not defined in the DT. Would you mind sending > > another patch to fix that, > > I looked into it, It looks like this: > > static int fsmc_nand_resume(struct device *dev) > { > struct fsmc_nand_data *host = dev_get_drvdata(dev); > > if (host) { > clk_prepare_enable(host->clk); > if (host->dev_timings) > fsmc_nand_setup(host, host->dev_timings); ->dev_timings is only allocated if timings are defined in the DT, but the driver can also let the framework configure the timings through the ->setup_data_interface() method (approach that should be preferred for all new boards). In this case ->dev_timings is NULL and we need to reset the chip to re-apply the timings. BTW, resetting the NAND chip at resume time is a sane thing to do if you want to start in known state, so I'd recommend adding nand_reset(&host->nand); here. > } > > return 0; > } > Regards, Boris ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/