Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1488727ybz; Sat, 25 Apr 2020 20:56:21 -0700 (PDT) X-Google-Smtp-Source: APiQypLVfwteRu0/BnhQwhtQYswE6FDHBBaZiD29rmFA6cpSSQ+rnn2Ii0EmYepHm6fp04MXjuT5 X-Received: by 2002:a05:6402:1713:: with SMTP id y19mr14268215edu.40.1587873381047; Sat, 25 Apr 2020 20:56:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587873381; cv=none; d=google.com; s=arc-20160816; b=sklLjKMIQmchXJBuC2gOjrD9eMiezMqwa+VJvTBOOm9aHfY07VEU5BxHWXORFCWN4V vKYnO2uv+4hvY+v4SBQur47m1kJwiHzLIjFaR9+CkqgOcVX5qV9SaqAivX8PgOaFd0t/ GvTSvZFeOwZ4/SpO/IDboKM9Y8P11E+LdHUerX6Iq8wcUZeycWZhR1L5UPIF+zE2Svzy y0lukiRTc0mP9O08ECgLGyexute1ZNBTGAhcTAPyBzhj0toGZNJc8Tyw2kS4AJjgd14c 2D4xuVVe5cLWeRJzS2bhXsGRdE1m2qdbUNoa/uyvX+xVvsevwBtPH0cKH7TjRb4977NO 17Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=LdzgaL6lGkNWHBi4dzGITh1yg50nRab3oYcY0FY16GY=; b=Jw9jp6cosus4tI8wjZQgjwhVo6Jdm9GZPZdsOHQfQq1K5bxbyupCh7M1YKEEBlFhYa T9ao6qUqJjlHojneo9+XDmekmdoSFniBOc4F2KgfeyuRVdXxsEVbndbdUA7Zyo2TxR3J /FWbqQGdALsFEMTDIaJWCT5Kx0nnLYodHBKPbZFeptup2FIIeFAVXm4jv/KjFCOrnFI6 neyoBZkcAW0WI1JAVQJV5Bu5mU06PrppyVk4rVfwPTWYhB0zlb6kg3Yh8tbHrFmNTrEM WiZy0EUsXK7WSIAuwyDZ3Y0lv1n18otRBNVTZL6TWme3/mXably3OQJx8JDAhyewCLwo v5Ag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h4si6539583ejo.186.2020.04.25.20.55.56; Sat, 25 Apr 2020 20:56:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726112AbgDZDxv (ORCPT + 99 others); Sat, 25 Apr 2020 23:53:51 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:35356 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726001AbgDZDxv (ORCPT ); Sat, 25 Apr 2020 23:53:51 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 93FE666F8A9BDA450EDB; Sun, 26 Apr 2020 11:53:49 +0800 (CST) Received: from [10.65.58.147] (10.65.58.147) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.487.0; Sun, 26 Apr 2020 11:53:45 +0800 Subject: Re: [PATCH v4 05/16] mtd: spi-nor: default to address width of 3 for configurable widths To: Pratyush Yadav , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mark Brown , Nicolas Ferre , Alexandre Belloni , Ludovic Desroches , , , , References: <20200424184410.8578-1-p.yadav@ti.com> <20200424184410.8578-6-p.yadav@ti.com> CC: Sekhar Nori From: Yicong Yang Message-ID: <6b6384ad-d37a-eea6-af29-322e83924912@hisilicon.com> Date: Sun, 26 Apr 2020 11:53:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20200424184410.8578-6-p.yadav@ti.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.65.58.147] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/4/25 2:43, Pratyush Yadav wrote: > JESD216D.01 says that when the address width can be 3 or 4, it defaults > to 3 and enters 4-byte mode when given the appropriate command. So, when > we see a configurable width, default to 3 and let flash that default to > 4 change it in a post-bfpt fixup. > > 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. > > Signed-off-by: Pratyush Yadav > --- > drivers/mtd/spi-nor/sfdp.c | 1 + > 1 file changed, 1 insertion(+) > > 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, > /* Number of address bytes. */ > switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) { > case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY: > + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: > nor->addr_width = 3; > break; Should we also assign address width to 3 in default condition. At least we should not leave it uninitialized here. Regards, Yicong >