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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2896CC433F5 for ; Mon, 8 Nov 2021 09:50:58 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 413F16125F for ; Mon, 8 Nov 2021 09:50:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 413F16125F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C78B883631; Mon, 8 Nov 2021 10:50:54 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="WemTDv4Q"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4F68783628; Mon, 8 Nov 2021 10:50:53 +0100 (CET) Received: from ssl.serverraum.org (ssl.serverraum.org [IPv6:2a01:4f8:151:8464::1:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 92DBF83201 for ; Mon, 8 Nov 2021 10:50:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from mwalle01.kontron.local. (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 611FC22246; Mon, 8 Nov 2021 10:50:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1636365048; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p35envRgAk8hTJytCw5iVESAwEsYO8gBCHvIRnzpPJg=; b=WemTDv4QHNbc8RklCEvX0HfoAyCqGRC+6R/WO5StWdwcrpEbWFttEvWyTEC3vEb4U1p8zy wosI9ksa9FElYWaKGTA5cDN9ICfIsZVA2bYPd3qCU9TGCLFLKOjyNS8ZRqpZCz6zbTw2mL eio588gc7He/qwTI46paoHTp7OfMKJ4= From: Michael Walle To: jagan@amarulasolutions.com Cc: Tudor.Ambarus@microchip.com, chao.zeng@siemens.com, chaochao2021666@163.com, jan.kiszka@siemens.com, trini@konsulko.com, u-boot@lists.denx.de, vigneshr@ti.com, Michael Walle Subject: Re: [PATCH] sf: Querying write-protect status before operating the Date: Mon, 8 Nov 2021 10:50:34 +0100 Message-Id: <20211108095034.2786054-1-michael@walle.cc> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean > On Fri, Nov 5, 2021 at 10:47 PM wrote: > > > > Hi, > > > > On 6/22/21 8:21 AM, chao zeng wrote: > > > From: Chao Zeng > > > > > > When operating the write-protection flash,spi_flash_std_write() and > > > spi_flash_std_erase() would return wrong result.The flash is protected, > > > but write or erase the flash would show "OK". > > > > > > Check the flash write protection state if the write-protection has enbale > > > before operating the flash. > > > > > > Signed-off-by: Chao Zeng > > > --- > > > > > > drivers/mtd/spi/sf_probe.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c > > > index 3befbe91ca..f06e6b88bd 100644 > > > --- a/drivers/mtd/spi/sf_probe.c > > > +++ b/drivers/mtd/spi/sf_probe.c > > > @@ -109,6 +109,11 @@ static int spi_flash_std_write(struct udevice *dev, u32 offset, size_t len, > > > struct mtd_info *mtd = &flash->mtd; > > > size_t retlen; > > > > > > + if (flash->flash_is_locked && flash->flash_is_locked(flash, offset, len)) { > > > + debug("SF: Flash is locked\n"); > > > + return -ENOPROTOOPT; > > > > Keep a debug message, but return 0 please. Writes or erases on protected areas > > are ignored by the flash, we should reflect that in the code. Mh, will this then make the whole write fail? We do rely on the fact, that we can update the whole flash image, but the first sectors will be 'skipped' because the first are write-protected. I guess this patch will then break this. Shouldn't this then be on a per sector basis? -michael