Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5415043pxj; Wed, 26 May 2021 09:58:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmA4ScED9tZQ4SrKfIqhb2JeiZh+stHT0vj2LrTEOCq8VWZnfmo3HmF1z+lto4F6XWJkgl X-Received: by 2002:a92:d60e:: with SMTP id w14mr26335586ilm.0.1622048324273; Wed, 26 May 2021 09:58:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622048324; cv=none; d=google.com; s=arc-20160816; b=w3X6hRgDR++E3ZgZdY8RpAoCjqv8YxwvJo2qwnZMElWloFrKPMVPrfSdzkLAb7n0+3 Y7i99mzcuoEoAcg2P8fAJURciyeBhKLPw+/Nx5DGIxiqbaAE+gi6MFSlh52KvSdxSVpu RHtsNE0fkpqfhcN5NePrQsuQJL1OjjValEtUI7/g0Ds+HIiocUzt9lqOnqgY9Gc9bPwf ZD0vspuCrRQ2q13Wmh/wkAJDz+yZhcKu79F/TcLK6F24TYARr418f514vE7r0UgRSdoo L7vOdMbce+F95O+C3QfGgV+0+1VPzuxi2CqwTYwhUby/8wCqATvVBnsJWLs+dNDvJ8wM QXHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=pkpy5vS1CMdOrnrcbFOZKe7b5M6sZdb+h+9h4pGCWLk=; b=CNLb2makdNcZyaQ31PrxO2S6KoV/nuJBpsRQv6isPp9fQueMN9SFwG5eArVv3wVcMi rVvlZk0dpD30h1jqisV6avJZS9FDX8QZqzgbWHIAaETZ2jEvtxxxXEcWTZpRwd17CWWY 8btAPW/vV0JrbovtS+BcX4J20iSgrHYLzw2nYUtQ1ZyGp1ieBT1itRUNtIbCdyTivv9I o3QJsxr1kyBhRiDgLsvKKU/c5qJ0VQ5m87IFKxsWhVizqutAawacf+i9eaj1F/KD+o9L LwENFnMw6doQP+cnf8Ubg5mmoK+pWS8D1WdL4qO5rW4owoQ2iZ7cKdS8udGfwHAoN7AU k6Hg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=eC1vcZUV; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p5si23940678ilm.11.2021.05.26.09.58.30; Wed, 26 May 2021 09:58:44 -0700 (PDT) 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=@ti.com header.s=ti-com-17Q1 header.b=eC1vcZUV; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234136AbhEZLPX (ORCPT + 99 others); Wed, 26 May 2021 07:15:23 -0400 Received: from fllv0015.ext.ti.com ([198.47.19.141]:49338 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234060AbhEZLPV (ORCPT ); Wed, 26 May 2021 07:15:21 -0400 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 14QBDakQ106453; Wed, 26 May 2021 06:13:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1622027616; bh=pkpy5vS1CMdOrnrcbFOZKe7b5M6sZdb+h+9h4pGCWLk=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=eC1vcZUVNuLToFVk4BZXRvQrtlEPxnf44ThLsYbK036/eQ0oBOC5utpI7udRbVKwJ Hw/+79bPQiY+cyz9NC2R5piRPZk8u5zFpq4kGmLGXzcy7WVitV1FIYey6szQ37LNzu +xfKrVq7ugLmK4vyhP0y8diFbRZuDWpn0ESaZHMU= Received: from DLEE112.ent.ti.com (dlee112.ent.ti.com [157.170.170.23]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 14QBDakc001847 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 May 2021 06:13:36 -0500 Received: from DLEE103.ent.ti.com (157.170.170.33) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 26 May 2021 06:13:36 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2 via Frontend Transport; Wed, 26 May 2021 06:13:36 -0500 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 14QBDZat034249; Wed, 26 May 2021 06:13:36 -0500 Date: Wed, 26 May 2021 16:43:35 +0530 From: Pratyush Yadav To: Michael Walle CC: , , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra Subject: Re: [PATCH v4 3/4] mtd: spi-nor: otp: return -EROFS if region is read-only Message-ID: <20210526111333.suxmmtkngqeyuz62@ti.com> References: <20210521194034.15249-1-michael@walle.cc> <20210521194034.15249-4-michael@walle.cc> <20210525193323.xdvbq3tab6oxk6yh@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/05/21 12:41PM, Michael Walle wrote: > Am 2021-05-25 21:33, schrieb Pratyush Yadav: > > On 21/05/21 09:40PM, Michael Walle wrote: > > > SPI NOR flashes will just ignore program commands if the OTP region is > > > locked. Thus, a user might not notice that the intended write didn't > > > end > > > up in the flash. Return -EROFS to the user in this case. From what I > > > can > > > tell, chips/cfi_cmdset_0001.c also return this error code. > > > > > > One could optimize spi_nor_mtd_otp_range_is_locked() to read the > > > status > > > register only once and not for every OTP region, but for that we would > > > need some more invasive changes. Given that this is > > > one-time-programmable memory and the normal access mode is reading, we > > > just live with the small overhead. > > > > Ok. > > > > > > > > Fixes: 069089acf88b ("mtd: spi-nor: add OTP support") > > > Signed-off-by: Michael Walle > > > --- > > > drivers/mtd/spi-nor/otp.c | 35 +++++++++++++++++++++++++++++++++++ > > > 1 file changed, 35 insertions(+) > > > > > > diff --git a/drivers/mtd/spi-nor/otp.c b/drivers/mtd/spi-nor/otp.c > > > index 3898ed67ba1c..b87f96593c13 100644 > > > --- a/drivers/mtd/spi-nor/otp.c > > > +++ b/drivers/mtd/spi-nor/otp.c > > > @@ -249,6 +249,31 @@ static int spi_nor_mtd_otp_info(struct mtd_info > > > *mtd, size_t len, > > > return ret; > > > } > > > > > > +static int spi_nor_mtd_otp_range_is_locked(struct spi_nor *nor, > > > loff_t ofs, > > > + size_t len) > > > +{ > > > + const struct spi_nor_otp_ops *ops = nor->params->otp.ops; > > > + unsigned int region; > > > + int locked; > > > + > > > + if (!len) > > > + return 0; > > > > I was inclined to say that the loop conditional below would take care of > > this but it can cause an underflow when ofs and len are both 0. > > Correct. I didn't want to put an extra check to the caller, because > as you noticed, it is checked by the loop there later. > > > > + > > > + /* > > > + * If any of the affected OTP regions are locked the entire range is > > > + * considered locked. > > > + */ > > > + for (region = spi_nor_otp_offset_to_region(nor, ofs); > > > + region <= spi_nor_otp_offset_to_region(nor, ofs + len - 1); > > > + region++) { > > > + locked = ops->is_locked(nor, region); > > > + if (locked) > > > + return locked; > > > + } > > > > Ok. > > Btw I didn't know if I should put a comment here that this if () handles > both locked state and errors. But it seems you've already found out by > looking at the caller ;) I'm not sure if this is obvious, though. I didn't catch this on the first read. I only figured it out when I looked at the return check below. So it is certainly not obvious. > > > > + > > > + return 0; > > > +} > > > + > > > static int spi_nor_mtd_otp_read_write(struct mtd_info *mtd, loff_t > > > ofs, > > > size_t total_len, size_t *retlen, > > > const u8 *buf, bool is_write) > > > @@ -271,6 +296,16 @@ static int spi_nor_mtd_otp_read_write(struct > > > mtd_info *mtd, loff_t ofs, > > > /* don't access beyond the end */ > > > total_len = min_t(size_t, total_len, spi_nor_otp_size(nor) - ofs); > > > > > > + if (is_write) { > > > + ret = spi_nor_mtd_otp_range_is_locked(nor, ofs, total_len); > > > + if (ret < 0) { > > > + goto out; > > > + } else if (ret) { > > > + ret = -EROFS; > > > > I wonder if we should have a dev_info() or dev_err() here. I think this > > warrants a dev_dbg() at least. > > Are you sure? Reporting something to the user via an error code is > enough IMHO. I wouldn't want my syslog to be cluttered with messages > I already know. I mean the program tell me "hey, you aren't allowed > to write there". Why would the kernel still need to tell me that again? > Without any connection to the caller, I don't get much out of the kernel > message by looking at it alone, just that someone tried to write there. > > So definetly no dev_info() or dev_err(). But IMHO no dev_dbg() either. > Tudor, Vingesh, any opinions? Either is fine by me. > > > > > + goto out; > > > + } > > > > So it returns -errno when the check for is_locked() fails and 1 or 0 > > when it is locked or not. Ok. > > > > It would be nice if you add a dev_dbg or dev_err() or dev_info() above. > > Nonetheless, > > > > Reviewed-by: Pratyush Yadav > > Thanks for reviewing! > > -michael -- Regards, Pratyush Yadav Texas Instruments Inc.