Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp497815pxb; Wed, 20 Jan 2021 12:12:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJyVZe4akUXqn/qKoXTvFbpOB5MqO0V3obScHrOjRRtQgUP8ZPbbS2YwSFMwSZfckAofoJfY X-Received: by 2002:aa7:db85:: with SMTP id u5mr8069647edt.107.1611173553339; Wed, 20 Jan 2021 12:12:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611173553; cv=none; d=google.com; s=arc-20160816; b=0PuUmUPAHKHkV077OZxX3tHN/kqGx/kM4duplN6lO/8V0WWlzbx3QIUJRwPC3E6c5e hJFZKAA7YPFJTG+caMYhBi4n10I+axKUtFzkDE0ZD6wJU50jW5gXyYTGRoxnUD6wV2Ti YRzPMwiTpgvna0ypOpPOP/YZs4ObHwAfWFqWcQl+LT1jxxOG+K5P+rSDUIUTggTSMI1k Bg+7zf6WJH79C4W92sYdA5ggfIUqz3P8Q1zbvEfmB5VxsjKLMRtauKAAe566qpMnLAeT 8vDAfIOHOG8FQsy//CUzOL8ta6r1eprgM6/vZ39MfP3DoctFt2iLTrcIOr8SN/KLdQXt be1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :dkim-signature; bh=jJzg+aAIebuXZDa7Uv1sg8IU5aWpIXkz9XqNxQ92KH8=; b=SaqSO59mktLQfgr9bGr91NkKSbSnNh7TkU7W4GdbSHpGxn1HVTZEMPwIxvdtVdF6/2 FzSEt9nu8sOoJzqYgSTkPWDZqN0Eix4q/jTM4oDjYLT80s/tUV8noNluyNxmWXviFsz3 p+B5FRMha0gBS6AFkuqIZ9zuoSuy94znMtmg/8Ipzcb6Ai0e/Dl/sDu6N0hqMNt5I78B 3faGuWLDZAT5n6udFRqJhUjwaflm285YUP+t6AZKVLSyFCEijVPLdAvW+iWejTotKB89 VuOlUU3y9aP5H7YnTRrVayv6BPQRvyBycvPHnGhVV3zeYi7vy5mSR5F3EPB0uIdzlpnS 9nkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=oP7V6Vup; 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 qc5si990473ejb.193.2021.01.20.12.12.09; Wed, 20 Jan 2021 12:12:33 -0800 (PST) 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; dkim=pass header.i=@walle.cc header.s=mail2016061301 header.b=oP7V6Vup; 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 S2389921AbhATUJl (ORCPT + 99 others); Wed, 20 Jan 2021 15:09:41 -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,