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: b5j2Cbd28r94XAaeNHmYvq6Wwtx3bhlYV7VOOzr3N7yfzWb7Gg3MCPLwe2vXmpdWGZT93Vzls7
 aSwAsFuouXFl6Ip4Sg5tJBfq65apnpnsY7+84sV2mxUZ4S3gIC7JXzRZCI2BgqjNGzHSPhq7tf
 +EOUlvZV2azAe3xjJ5IFKvdX5jLBZAxx6/dvNunL1hi+EPm4UUOHBrNK1WuofVgJ18slIyZAtB
 vd+cICm+sjZOIe3118StTq6i80reLXseSvDpH/XY320FOpLs3lDEXIoGHRXJ2AO4YOV5q/6CEq
 gYU=
From:   <Tudor.Ambarus@microchip.com>
To:     <yangyicong@hisilicon.com>
CC:     <me@yadavpratyush.com>, <p.yadav@ti.com>,
        <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 05/16] mtd: spi-nor: default to address width of 3 for
 configurable widths
Thread-Topic: [PATCH v4 05/16] mtd: spi-nor: default to address width of 3 for
 configurable widths
Thread-Index: AQHWHLkjDWuKSC8VwkCztQzj3fjN/6iNwPMAgABAZYA=
Date:   Tue, 28 Apr 2020 05:25:17 +0000
Message-ID: <2970660.P4alVuHkju@192.168.0.120>
References: <20200424184410.8578-1-p.yadav@ti.com>
 <20200427172336.ihezwq3wn75m7k3l@yadavpratyush.com>
 <f6a593ab-8685-18e0-04c8-25edd1cab11a@hisilicon.com>
In-Reply-To: <f6a593ab-8685-18e0-04c8-25edd1cab11a@hisilicon.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microchip.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F1C82EB13DDCBB4987623865C3BAB382@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 095a901a-fb80-4d4a-3d5e-08d7eb34897b
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 05:25:17.2177
 (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: is1jLxdD6o3cL5bz14IJTy4tikIHjTBNkM+MFjmX0CYSOOChgkwqdmDA3LeF/0H8L0kr6eF/CafXIbpsARFH5qD8YvioZ596LEsvRyzTqZc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4388
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 Tuesday, April 28, 2020 4:34:46 AM EEST Yicong Yang wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know th=
e
> content is safe
>=20
> Hi Pratyush,
>=20
> On 2020/4/28 1:23, Pratyush Yadav wrote:
> > Hi Yicong,
> >=20
> > On 26/04/20 11:53AM, Yicong Yang wrote:
> >> On 2020/4/25 2:43, Pratyush Yadav wrote:
> >>> JESD216D.01 says that when the address width can be 3 or 4, it defaul=
ts
> >>> to 3 and enters 4-byte mode when given the appropriate command. So, w=
hen
> >>> we see a configurable width, default to 3 and let flash that default =
to
> >>> 4 change it in a post-bfpt fixup.
> >>>=20
> >>> This fixes SMPT parsing for flashes with configurable address width. =
If
> >>> the SMPT descriptor advertises variable address width, we use
> >>> nor->addr_width as the address width. But since it was not set to any
> >>> value from the SFDP table, the read command uses an address width of =
0,
> >>> resulting in an incorrect read being issued.
> >>>=20
> >>> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> >>> ---
> >>>=20
> >>>  drivers/mtd/spi-nor/sfdp.c | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>=20
> >>> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> >>> index f917631c8110..5cecc4ba2141 100644
> >>> --- a/drivers/mtd/spi-nor/sfdp.c
> >>> +++ b/drivers/mtd/spi-nor/sfdp.c
> >>> @@ -460,6 +460,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor=
,
> >>>=20
> >>>     /* Number of address bytes. */
> >>>     switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MA=
SK)
> >>>     {
> >>>=20
> >>>     case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
> >>> +   case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4:
> >>>             nor->addr_width =3D 3;
> >>>             break;
> >>=20
> >> Should we also assign address width to 3 in default condition. At leas=
t
> >> we should not leave it uninitialized here.
> >=20
> > The default condition would be taken when this field is 3. The value 3
> > is reserved, and so no current device should use this value. That said,
> > I don't see any downsides of doing so. If the value 3 means something
> > else in later revisions of the standard, this code would need to change
> > anyway. If not, we would use a relatively sane default for devices with
> > a faulty BFPT.
>=20
> The purpose is to set one possible value which may be used later in parsi=
ng
> smpt. In current driver, if we do nothing with the post-bfpt fixup, then
> the width will be unset. Otherwise, maybe the width can also be set in
> spi_nor_smpt_addr_width()
>=20
>     default:
>    +    if (!nor->addr_width)
>    +        nor->addr_width =3D 3;
>         return nor->addr_width;
>=20
> But set when parsing bfpt seems more reasonable.

Please don't. Any deviations from the standard should be addressed with fix=
up=20
hooks.

>=20
> > I haven't received any comments on my series so far. If end up having t=
o

Thanks for the patience, they are in my todo list, I will get soon to them.

Cheers,
ta