Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: EArsk8vci0zaHCMJ4YfSsDBBafyLIhKA9+k/VCZL0A8lIN7+OJV5nPKwm5I+RFYLVzy6vg2QZH
 gwitZb5TxstPJVFsfDCP5dcy8sdJGGRIQkRCsiwQvqDWvP31x9vSCFF+hzedVyQkGS1rMBdAnu
 s9nvCmHrhsnmP3eHR0bjomucHK6X+mZai+BDAgpd+5TPwSojnb4+yYVeqazQF1IspFvzMLv284
 BXx5jC3+hlQSuhnffkkwyyGTSZCmeyh/jwjm9xUKFxX7T42apa9LA+uOEdjHS3FuhyXcxuAjp0
 v5g=
From:   <Tudor.Ambarus@microchip.com>
To:     <boris.brezillon@collabora.com>
CC:     <p.yadav@ti.com>, <alexandre.belloni@bootlin.com>,
        <vigneshr@ti.com>, <richard@nod.at>, <nsekhar@ti.com>,
        <Nicolas.Ferre@microchip.com>, <linux-kernel@vger.kernel.org>,
        <Ludovic.Desroches@microchip.com>, <broonie@kernel.org>,
        <linux-mtd@lists.infradead.org>, <miquel.raynal@bootlin.com>,
        <linux-spi@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
Thread-Topic: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
Thread-Index: AQHWJ3Khn/aolf/mv0usqjltSIxTLg==
Date:   Tue, 12 May 2020 06:16:52 +0000
Message-ID: <144878625.o7txgtY6sz@192.168.0.120>
References: <20200424184410.8578-1-p.yadav@ti.com>
 <3649933.zuh8VGJVCz@192.168.0.120> <20200511112712.466f7246@collabora.com>
In-Reply-To: <20200511112712.466f7246@collabora.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8D67A0AB6DDE6549B9366E73092AA3CD@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ad52947-c446-41ae-9f59-08d7f63c101d
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 06:16:52.3332
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0GPt2Yiz5THlRm+joYY2rNA1gmxGkanf+hah/HKpYQa95w6f84nR4Sddg4dmP7F1oOOHLMPUMqyFTppuDjRC59Ot5NI/VDJiKmfrcbV7QF8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4291
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 th=
e
> content is safe
>=20
> On Mon, 11 May 2020 09:00:35 +0000
>=20
> <Tudor.Ambarus@microchip.com> wrote:
> > Hi, Pratyush, Boris,
> >=20
> > 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 framewo=
rk,
> >=20
> > 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 dangerou=
s
> > 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 t=
he
> > next power-on. I guess this is conditioned by the optional RESET pin, b=
ut
> > I'll have to check. Also the flash can return to the 1-1-1 mode using t=
he
> > software reset or through writing to its Configuration Register, withou=
t
> > power-on or power- off.
>=20
> 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.
>=20

The software reset procedure can't protect you from unexpected resets, but =
the=20
hardware with its optional reset pin can. Pratyush to confirm.

cut

>=20
> > Not recovering from unexpected resets is unacceptable. One should alway=
s
> > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 w=
ith
> > the presence of the optional RESET pin.
>=20
> 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 t=
he=20
presence of the optional RESET pin. We would introduce an optional device t=
ree=20
property for the RESET pin. If hardware doesn't implement the optional RESE=
T#=20
signal, then we will not enter in the state-full modes.

Cheers,
ta