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: W7v7F3fePcC79mASEJuRUi2aeRbMisK56hJ5pb8/Z0MEMXddV04zkxIM/DS0KkHCB8cwJbfKtZ
 sOV1zFJ489f6rwxwBzRwXeU5BEf0c1MWhHj0M9HlXlZEbMgYq4KWEftTSfe7VvHAb9ZocR7E5A
 vQK/iHjprASF+UGEF62XEegOINB0ZlYuJK5FXWActVloXTDt9vD8WVD6RbqSnRjOR2UPZ+wfYq
 0ohMZzy9hrKO+rWdOvx2zVfvj+6QA9kyAhupxS7/mCAz3p1ZGbQ8rDID9o3F6TF63jdg07D4lv
 vM8=
From:   <Tudor.Ambarus@microchip.com>
To:     <p.yadav@ti.com>, <boris.brezillon@collabora.com>
CC:     <miquel.raynal@bootlin.com>, <richard@nod.at>, <vigneshr@ti.com>,
        <broonie@kernel.org>, <Nicolas.Ferre@microchip.com>,
        <alexandre.belloni@bootlin.com>, <Ludovic.Desroches@microchip.com>,
        <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        <linux-spi@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, <nsekhar@ti.com>
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:   Mon, 11 May 2020 09:00:35 +0000
Message-ID: <3649933.zuh8VGJVCz@192.168.0.120>
References: <20200424184410.8578-1-p.yadav@ti.com>
In-Reply-To: <20200424184410.8578-1-p.yadav@ti.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FC1D03ED70AB18478EDAF0B070DEC3BA@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 92a278c0-aece-4143-0505-08d7f589c47d
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 09:00:35.0417
 (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: sPFMgUsS60Ng6GTw35EFXYBzZNSRfKeHnUj6l6W59l0y1Yc9YdPYG0V0t3vH6gWN6QgSz44LRUraa1s0LYN3xvqpqDOfFBuMCrWJlKLW15Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3975
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, 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=
=20
open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous=20
because the flash may not recover from unexpected resets. Entering one of=20
these modes can be:
1/ volatile selectable, the device return to the 1-1-1 protocol after the n=
ext=20
power-on. I guess this is conditioned by the optional RESET pin, but I'll h=
ave=20
to check. Also the flash can return to the 1-1-1 mode using the software re=
set=20
or through writing to its Configuration Register, without power-on or power=
-
off.
2/ non-volatile selectable in which RESET# and software reset are useless, =
the=20
flash defaults to the mode selected in the non volatile Configuration Regis=
ter=20
bits. The only way to get back to 1-1-1 is to write to the Configuration=20
Register.

Not recovering from unexpected resets is unacceptable. One should always=20
prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with =
the=20
presence of the optional RESET pin.

For the unfortunate flashes that support just option 2/, we should not ente=
r=20
these modes on our own, just by discovering the capabilities from the SFDP=
=20
tables or by the flags in the flash_info struct. The best we can do for the=
m=20
is to move the responsibility to the user. Maybe to add a Kconfig option th=
at=20
is disabled by default with which we condition the entering in 2-2-2, 4-4-4=
 or=20
8-8-8 modes. Once entered in one of these modes, if an unexpected reset com=
es,=20
you most likely are doomed, because early stage bootloaders may not work in=
=20
these modes and you'll not be able to boot the board. Assuming that one use=
s=20
other environment to boot the board, we should at least make sure that the=
=20
flash works in linux after an unexpected reset. We should try to determine =
in=20
which mode we are at init, so maybe an extension of the default_init hook i=
s=20
needed. But all this looks like a BIG compromise, I'm not yet sure if we=20
should adress 2/. Thoughts?

I'm still looking into this.

Cheers,
ta