Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1051500img; Mon, 18 Mar 2019 22:23:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqzSayiGe3pM28Xcstua0uY8WEMuW3uIdqV2R+yC25fvxaDvIUQV8gOc4J5QWTNVIpq8n/ni X-Received: by 2002:a17:902:28a7:: with SMTP id f36mr145310plb.169.1552973005133; Mon, 18 Mar 2019 22:23:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552973005; cv=none; d=google.com; s=arc-20160816; b=Bx/V5ZY30wldrgCp45uOjk/uy5XF87Zdwy93G4gRZiEMxtGDHi7JnpxlL6YFxMkC62 2WbsSfpOBqz1t8kwso/pOeFRW4jMJguDJFu0eI/U6JVL4dJl0gYtI3uPyQ/SM0rpf6Dm zUfqX8Y44Dku7TPTQ8pevS0OL52AJLh8iduJAwJD3WW2Ne7fhF2dUrnjw7rHi5W4nj/5 RZ2rbaQYozx6u0lVXPOeN6GniEkQfWLPb7qas4JsW85dX+UKeMYB/sOb6viy378bREj2 6sTdDGmBbwvF5Yj3U0QObvEkmjET8fjOjVYIqYKzIEfFtLHq/O41x3XksOha3fqW4fKf QCUw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Bpl/Fv73gU5NRDM5ZU/uZIdXbp+7aObdaoG12KrtD7o=; b=Z5LowEuNTSIKwXW/ynILbgioNQGqwuc8qC6+7x3m6Vt2zeTbwUBiog+RNsEkejtim4 hlI6pjJqhETBvtOHy4WtsfqY7IuDJfilZS74+UW06azt4N1Oz+zHM/uuPWh5m+9H9PAY GG7GoGz4jjZGnWQsZ4dKO64far1bzfDzk8LWHs6aLjDPk/bGloiba9aitZAOEH5yTrOe qJvs787ZM21DXN7b1tDBi5I/ATGWjOcYKBmXmsims0bZ3QTul/0x+4aikFHxpVB/UPTl +iAIcUNVsQsKb2c5pbiqy8xX617v6iGTnxVHQcfi6kwT6wjV0JJqNuheBw9PfzLalcw3 0RzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=giMzL9Vr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e65si11273718pfa.80.2019.03.18.22.23.09; Mon, 18 Mar 2019 22:23:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=giMzL9Vr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727217AbfCSFWI (ORCPT + 99 others); Tue, 19 Mar 2019 01:22:08 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:59494 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbfCSFWH (ORCPT ); Tue, 19 Mar 2019 01:22:07 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id x2J5LN5p026746; Tue, 19 Mar 2019 00:21:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1552972883; bh=Bpl/Fv73gU5NRDM5ZU/uZIdXbp+7aObdaoG12KrtD7o=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=giMzL9Vrv/Wn7hJMPr+jM6U560o14WKxzJWwSKE8hVVfJB+VeUIXr6Bt9GFlLV1ls GaGfVXO9+vqE+/d/ccz03/RIm3pFiIsX8hoF3HcKlHUZneKys+gqkyZWECfQk33fq5 AROVSWa6OR+xmpo5+CkUnzhNiYL8CQlcxJJQ3TiM= Received: from DLEE107.ent.ti.com (dlee107.ent.ti.com [157.170.170.37]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x2J5LN4T106964 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 19 Mar 2019 00:21:23 -0500 Received: from DLEE114.ent.ti.com (157.170.170.25) by DLEE107.ent.ti.com (157.170.170.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 19 Mar 2019 00:21:22 -0500 Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 19 Mar 2019 00:21:22 -0500 Received: from [172.24.190.89] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id x2J5LHks023380; Tue, 19 Mar 2019 00:21:18 -0500 Subject: Re: [PATCH v2] mtd: spi-nor: Return error when nor->addr_width does not match the device size To: Liu Xiang , CC: , , , , , , References: <1552484753-3393-1-git-send-email-liu.xiang6@zte.com.cn> From: Vignesh Raghavendra Message-ID: <823dcd3f-8b9f-15c5-a072-06625120766e@ti.com> Date: Tue, 19 Mar 2019 10:52:15 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1552484753-3393-1-git-send-email-liu.xiang6@zte.com.cn> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 13/03/19 7:15 PM, Liu Xiang wrote: > In some is25lp256, the DWORD1 of JEDEC Basic Flash Parameter Header > is 0xfff920e5. So the DWORD1[18:17] Address Bytes bits are 0b00, > means that 3-Byte only addressing. But the device size is larger > than 16MB, nor->addr_width must be 4 to access the whole address. > An error should be returned when nor->addr_width does not match > the device size in spi_nor_parse_bfpt(). Then it can go back to > use spi_nor_ids[] for setting the right addr_width. > > Suggested-by: Boris Brezillon > Signed-off-by: Liu Xiang > --- > drivers/mtd/spi-nor/spi-nor.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index 6e13bbd..63933c7 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -2811,6 +2811,14 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, > } > params->size >>= 3; /* Convert to bytes. */ > > + /* > + * If the device exceeds 16MiB, addr_width must be 4. > + * addr_width == 3 means the Address Bytes we are > + * reading from BFPT is wrong. > + */ JESD216 standard does not mandate flash devices >16MiB to always support 4 byte addressing opcode. So, its okay for flash vendor to support >16MiB flash with 3 byte addressing and Bank/extended address register. > + if (params->size > 0x1000000 && nor->addr_width == 3) > + return -EINVAL; > + Assuming only DWORD1[18:17] bits are wrong, then returning from here would mean we miss parsing Sector Erase settings, Quad Enable Requirements etc from BFPT which is kind of bad. I suggest to move the fix to[1], addr_width indicated in flash_info struct of the device can take precedence over SFDP. [1]https://elixir.bootlin.com/linux/latest/source/drivers/mtd/spi-nor/spi-nor.c#L4106 > /* Fast Read settings. */ > for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_reads); i++) { > const struct sfdp_bfpt_read *rd = &sfdp_bfpt_reads[i]; > -- Regards Vignesh