From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.bootlin.com ([62.4.15.54]) by merlin.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gNFAi-0001eG-Ed for linux-mtd@lists.infradead.org; Thu, 15 Nov 2018 10:46:53 +0000 Date: Thu, 15 Nov 2018 11:46:20 +0100 From: Boris Brezillon To: Cc: , , , , , , Subject: Re: [RFC] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories Message-ID: <20181115114620.36ff32c7@bbrezillon> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 14 Nov 2018 08:00:44 +0000 wrote: > Hi, Alexander, > > On 11/13/2018 06:58 PM, Sverdlin, Alexander (Nokia - DE/Ulm) wrote: > > Hello Tudor and all, > > > > first of all, thank you for your work on SFDP support in Linux! > > > > Unfortunately, I'm debugging a regression caused by 5390a8df769ec > > "mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories" > > in [out of tree] support for S25FS128S. > > > > The culprit is the following part of your patch: > > > > /* > > * For non-uniform SPI flash memory, set mtd->erasesize to the > > * maximum erase sector size. No need to set nor->erase_opcode. > > */ > > for (i = SNOR_ERASE_TYPE_MAX - 1; i >= 0; i--) { > > if (map->erase_type[i].size) { > > erase = &map->erase_type[i]; > > break; > > } > > } > > > > The problem in our case is, we have existing partitioning with 128k partitions > > (the Flash itself supports 256k and 64k erasesize, depending on configuration). > > The chip is configured for 64k erasesize, non-uniform mapping. > > > > The mapping itself is being detected correctly, but when it comes to the code > > snippet above, it selects the biggest erasesize from all sizes advertised in > > SFDP, including 256k, which is not applicable to the current configuration. > > The fix would be to save the supported erase types when parsing the SFDP SMPT > table and use those instead. Alexander, Tudor, can one of you work on such a fix?