Richard, You have any other review comments/concerns with this patch, if not can you please sign off on it. Thanks Kamal On Fri, May 17, 2019 at 7:56 AM Kamal Dasu <kdasu.kdev@xxxxxxxxx> wrote: > > On Fri, May 17, 2019 at 4:12 AM Richard Weinberger > <richard.weinberger@xxxxxxxxx> wrote: > > > > On Thu, May 16, 2019 at 6:42 PM Kamal Dasu <kdasu.kdev@xxxxxxxxx> wrote: > > > > > > If mtd_oops is in progress, switch to polling during NAND command > > > completion instead of relying on DMA/interrupts so that the mtd_oops > > > buffer can be completely written in the assigned NAND partition. > > > > With the new flag the semantics change, as soon a panic write happened, > > the flag will stay and *all* future operates will take the polling/pio path. > > > > Yes that is true. > > > IMHO this is fine since the kernel cannot recover from an oops. > > But just to make sure we all get this. :-) > > An alternative would be to block all further non-panic writes. > > Capturing the panic writes into an mtd device reliably is what the low > level driver is trying to do.If there are non panic writes they will > use pio and interrupt polling as well in this case. > > > -- > > Thanks, > > //richard > > Thanks > Kamal ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/