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: bWPL3/hQ8j8fexYACHh9eH+UYEc86To7sOcEoDGl3iPB9KARqxvTsOXU1k0H19kpeSxd++fkUr
 kUaDjoYuyotgiM7FEtJRrcCfgDohSj8/VdDcAgAtlY0TXZ8/yVvfDyIc0nIboinGyMW+SWJOKv
 nOodcNLK5rIgdl3t0teHZXvhbLv1yAbVfBwGSzMBgOvq6vqyC1AsJ9Cnk1qV8rwlYliOP20EaE
 F6t4dB/vvWWrF/UqKs4BCkJIoh2WxnhZs0ohj3WuNjoQ6uoAZSRTjg10uGQVN+6VVR23K3QAsZ
 Uc8=
From:   <Tudor.Ambarus@microchip.com>
To:     <danielwa@cisco.com>
CC:     <xe-linux-external@cisco.com>, <miquel.raynal@bootlin.com>,
        <richard@nod.at>, <vigneshr@ti.com>,
        <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC-PATCH] mtd: spi-nor: add conditional 4B opcodes
Thread-Topic: [RFC-PATCH] mtd: spi-nor: add conditional 4B opcodes
Thread-Index: AQHWJrfbDyLqorcjbUikOW2Luyi/yw==
Date:   Sun, 10 May 2020 10:43:36 +0000
Message-ID: <27176656.kDElnbHIDG@192.168.0.120>
References: <20200507162047.30788-1-danielwa@cisco.com>
In-Reply-To: <20200507162047.30788-1-danielwa@cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19D37A7124EA794F8496FE49201C746B@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fb269575-d07d-4f12-ee0c-08d7f4cefe8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 10:43:36.6375
 (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: sk9mfRXOLfpPSOtJy9BvuWTQXFhgabn65VM4dUPkT6lLow8M1++9WkHdRh2lsaxHCx11XyqpjXxURHKr50GpQqjCeCkDkWaopRGIvtqPOy0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4369
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, Daniel,

On Thursday, May 7, 2020 7:20:47 PM EEST Daniel Walker wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know th=
e
> content is safe
>=20
> Some chips have 4B opcodes, but there is no way to know if they have
> them. This device tree option allows platform owners to force enable 4b
> opcodes when they know their chips support it even when it can be
> automatically identified.

I would like to detect this at run-time if possible. Maybe we can distingui=
sh=20
between the flavors of your flash by inspecting BFPT[16], bit 29. I'm plann=
ing=20
to parse the 16th dword of BFPT. What does your flash return after applying=
=20
the following patch?

diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index f6038d3a3684..99f0ce57c7d0 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -457,6 +457,10 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
        /* Fix endianness of the BFPT DWORDs. */
        le32_to_cpu_array(bfpt.dwords, BFPT_DWORD_MAX);
=20
+       for(i =3D 0; i < BFPT_DWORD_MAX; i++)
+               dev_err(nor->dev, "bfpt.dwords[%d] =3D %08x\n",
+                       i + 1, bfpt.dwords[i]);
+
        /* Number of address bytes. */
        switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK=
) {
        case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
@@ -972,6 +976,9 @@ static int spi_nor_parse_4bait(struct spi_nor *nor,
        /* Fix endianness of the 4BAIT DWORDs. */
        le32_to_cpu_array(dwords, SFDP_4BAIT_DWORD_MAX);
=20
+       for(i =3D 0; i < SFDP_4BAIT_DWORD_MAX; i++)
+               dev_err(nor->dev, "4bait[%d] =3D %08x\n", i, dwords[i]);
+
        /*
         * Compute the subset of (Fast) Read commands for which the 4-byte
         * version is supported.