Hi, Boris, Pratyush, I stripped case 2/, we'll not treat it for now. On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Mon, 11 May 2020 09:00:35 +0000 > > <Tudor.Ambarus@xxxxxxxxxxxxx> wrote: > > Hi, Pratyush, Boris, > > > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: > > > This series adds support for octal DTR flashes in the spi-nor framework, > > > > I'm still learning about this, but I can give you my 2 cents as of now, to > > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > > because the flash may not recover from unexpected resets. Entering one of > > these modes can be: > > 1/ volatile selectable, the device return to the 1-1-1 protocol after the > > next power-on. I guess this is conditioned by the optional RESET pin, but > > I'll have to check. Also the flash can return to the 1-1-1 mode using the > > software reset or through writing to its Configuration Register, without > > power-on or power- off. > > My understanding is that there's no standard software reset procedure > that guarantees no conflict with existing 1S commands, so even the > software reset approach doesn't work here. > The software reset procedure can't protect you from unexpected resets, but the hardware with its optional reset pin can. Pratyush to confirm. cut > > > Not recovering from unexpected resets is unacceptable. One should always > > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with > > the presence of the optional RESET pin. > > Totally agree with you on that one, but we know what happens in > practice... What I proposed is to condition the entering in the state-full modes with the presence of the optional RESET pin. We would introduce an optional device tree property for the RESET pin. If hardware doesn't implement the optional RESET# signal, then we will not enter in the state-full modes. Cheers, ta