From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFB31C433E6 for ; Wed, 20 Jan 2021 20:09:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B7FEC23441 for ; Wed, 20 Jan 2021 20:09:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389948AbhATUJx (ORCPT ); Wed, 20 Jan 2021 15:09:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389893AbhATOGG (ORCPT ); Wed, 20 Jan 2021 09:06:06 -0500 Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43B9BC061575 for ; Wed, 20 Jan 2021 06:05:24 -0800 (PST) Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 4BC0522727; Wed, 20 Jan 2021 15:05:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1611151522; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jJzg+aAIebuXZDa7Uv1sg8IU5aWpIXkz9XqNxQ92KH8=; b=oP7V6Vupj72Em3tLWu3ImkXDWlbnPRiZyV5Hawk8Qh0CjaXOjG52zeF8GGEPFY1s3vQ53e Xv1phw41hSMy0XxgTeikuPio+EUPRXO8y0uvkrMhJweN9vCS45DpCD+sCsCHt0zy373vAt 3+f19Gl1Wh559tbKhTCrwN8EIiEXJjs= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 20 Jan 2021 15:05:22 +0100 From: Michael Walle To: Tudor Ambarus Cc: vigneshr@ti.com, p.yadav@ti.com, miquel.raynal@bootlin.com, richard@nod.at, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Kavyasree.Kotagiri@microchip.com Subject: Re: [PATCH v2 2/2] mtd: spi-nor: sst: Add support for Global Unlock on sst26vf In-Reply-To: <20210120131914.277363-2-tudor.ambarus@microchip.com> References: <20210120131914.277363-1-tudor.ambarus@microchip.com> <20210120131914.277363-2-tudor.ambarus@microchip.com> User-Agent: Roundcube Webmail/1.4.10 Message-ID: X-Sender: michael@walle.cc Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2021-01-20 14:19, schrieb Tudor Ambarus: > Even if sst26vf shares the SPINOR_OP_GBULK opcode with > Macronix (ex. MX25U12835F) and Winbound (ex. W25Q128FV), > it has its own Individual Block Protection scheme, which > is also capable to read-lock individual parameter blocks. > Thus the sst26vf's Individual Block Protection scheme will > reside in the sst.c manufacturer driver. > > Add support to unlock the entire flash memory. The device > is write-protected by default after a power-on reset cycle > (volatile software protection), in order to avoid inadvertent > writes during power-up. Could do an erase, write, read back, > and compare when MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE=y. > > Signed-off-by: Tudor Ambarus > --- Damn, who on earth assigned the "block protection" bits to the 8/32/64kb sectors on the flash (SST26VF064B DS, Table 5-6). That is nuts. Except one comment below: Reviewed-by: Michael Walle > v2: s/!ofs/ofs == 0/ > > drivers/mtd/spi-nor/sst.c | 38 ++++++++++++++++++++++++++++++++++++-- > 1 file changed, 36 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c > index 00e48da0744a..d6e1396abb96 100644 > --- a/drivers/mtd/spi-nor/sst.c > +++ b/drivers/mtd/spi-nor/sst.c > @@ -8,6 +8,39 @@ > > #include "core.h" > > +static int sst26vf_lock(struct spi_nor *nor, loff_t ofs, uint64_t len) > +{ > + return -EOPNOTSUPP; > +} > + > +static int sst26vf_unlock(struct spi_nor *nor, loff_t ofs, uint64_t > len) > +{ > + if (ofs == 0 && len == nor->params->size) > + return spi_nor_global_block_unlock(nor); Some blocks might not be unlocked because they are permanently locked. Does it make sense to read BPNV of the control register and add a debug message here? -michael > + > + return -EOPNOTSUPP; > +} > + > +static int sst26vf_is_locked(struct spi_nor *nor, loff_t ofs, uint64_t > len) > +{ > + return -EOPNOTSUPP; > +} > + > +static const struct spi_nor_locking_ops sst26vf_locking_ops = { > + .lock = sst26vf_lock, > + .unlock = sst26vf_unlock, > + .is_locked = sst26vf_is_locked, > +}; > + > +static void sst26vf_default_init(struct spi_nor *nor) > +{ > + nor->params->locking_ops = &sst26vf_locking_ops; > +} > + > +static const struct spi_nor_fixups sst26vf_fixups = { > + .default_init = sst26vf_default_init, > +}; > + > static const struct flash_info sst_parts[] = { > /* SST -- large erase sizes are "overlays", "sectors" are 4K */ > { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, > @@ -39,8 +72,9 @@ static const struct flash_info sst_parts[] = { > { "sst26vf016b", INFO(0xbf2641, 0, 64 * 1024, 32, > SECT_4K | SPI_NOR_DUAL_READ) }, > { "sst26vf064b", INFO(0xbf2643, 0, 64 * 1024, 128, > - SECT_4K | SPI_NOR_DUAL_READ | > - SPI_NOR_QUAD_READ) }, > + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | > + SPI_NOR_HAS_LOCK | SPI_NOR_SWP_IS_VOLATILE) > + .fixups = &sst26vf_fixups }, > }; > > static int sst_write(struct mtd_info *mtd, loff_t to, size_t len,