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-PHdr: =?us-ascii?q?9a23=3AGnegnR/TKW1auP9uRHGN82YQeigqvan1NQcJ65?=
 =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?=
 =?us-ascii?q?oMiMEYhQslVcKMD0z2KOHjRyc7B89FElRi+iLzPA=3D=3D?=
From:   "Daniel Walker (danielwa)" <danielwa@cisco.com>
To:     "Tudor.Ambarus@microchip.com" <Tudor.Ambarus@microchip.com>
CC:     "xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
        "miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
        "richard@nod.at" <richard@nod.at>,
        "vigneshr@ti.com" <vigneshr@ti.com>,
        "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd: spi-nor: Add 4B_OPCODES flag to n25q256a
Thread-Topic: [PATCH] mtd: spi-nor: Add 4B_OPCODES flag to n25q256a
Thread-Index: AQHWF/lMc3ECMdgUBUCVtkLu7h92/g==
Date:   Tue, 21 Apr 2020 16:24:14 +0000
Message-ID: <20200421162414.GE9016@zorba>
References: <20200417174620.16420-1-danielwa@cisco.com>
 <12178429.kzmL6e4XO6@192.168.0.120> <20200420162550.GZ24466@zorba>
 <9715610.TpusJ8o3lr@192.168.0.120>
In-Reply-To: <9715610.TpusJ8o3lr@192.168.0.120>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Mutt/1.9.4 (2018-02-28)
received-spf: None (protection.outlook.com: cisco.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29FDC119F0A59D43AFF5BA83E79ED2F4@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 53c63e6f-c566-4731-c935-08d7e6106ec9
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 16:24:14.7478
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /ZHsy4zJWSxU+koYnG8e4iXcg8JFqXFnGqbOxGTuVDcv3/YDL+SHeY/OnxSq1PKDH8Gq6PRnlnlsfVXW+jxdUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3287
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 21, 2020 at 04:52:01AM +0000, Tudor.Ambarus@microchip.com wrote=
:
> On Monday, April 20, 2020 7:25:51 PM EEST Daniel Walker (danielwa) wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know =
the
> > content is safe
> > On Mon, Apr 20, 2020 at 03:45:59PM +0000, Tudor.Ambarus@microchip.com w=
rote:
> > > Hi, Daniel,
> > >=20
> > > On Friday, April 17, 2020 8:46:19 PM EEST Daniel Walker wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you k=
now
> > > > the
> > > > content is safe
> > > >=20
> > > > The n25q256a supports 4-byte opcodes so lets add the flag.
> > >=20
> > > This is not true for all the n25q256a flashes. SPINOR_OP_PP_4B,
> > > SPINOR_OP_BE_4K_4B and SPINOR_OP_SE_4B are valid just for the part nu=
mbers
> > > N25Q256A83ESF40x, N25Q256A83E1240x, and N25Q256A83ESFA0F.
> > >=20
> > > You need to differentiate between the aforementioned flashes and the =
rest
> > > in the n25q256a, in order to add the 4-byte opcodes flag.
> >=20
> > How do you suggest I do that ? Can I add a new entry into this table wi=
th
> > more specific information about the chips ?
> >=20
>=20
> We need to find a differentiator at runtime. If we are lucky, there might=
 be=20
> some SFDP changes between the 4-byte opcodes capable flashes and the rest=
.=20
> Please dump all the sfdp tables, we can start from there. There's a threa=
d=20
> that might interest you, see http://u-boot.10912.n7.nabble.com/Regression=
s-in-MTD-SPI-FLASH-td382956.html#a383126.
=20
The thread seems to indicate that it's not easy to identify the chips which
support this.

Inside our device tree we identify that our flash is compatible with,
compatible =3D "jedec,spi-nor";

Would it make sense to add further identification of the chips into the dev=
ice
tree, or allow some level of control over the SPI_NOR_4B_OPCODES flag into =
the
device tree. Since it would seems identification of the chips is not trivia=
l.

> A more elegant way to solve it, is by parsing the 4bait sfdp table, but I=
=20
> haven't checked if this flash supports it or not. Anyway, not something t=
hat=20
> we can control, the manufacturer should add it.

We can investigate, our hardware team is claiming the only way to know if
physically reading what's on the chip.

Daniel=