Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp406098pxj; Thu, 27 May 2021 03:07:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJws+Ul5NdSkl+Q3aq0JKer9xAKqL4/xc5LFwxiwniHF+cshUy1YmY8WBTQsROAFwWETQ6IZ X-Received: by 2002:a17:906:f20e:: with SMTP id gt14mr2874986ejb.368.1622110020446; Thu, 27 May 2021 03:07:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622110020; cv=none; d=google.com; s=arc-20160816; b=0VL2xQL4pZkOpiezWNrboxcy4RIkDoT6LnMv/eTDSMXs4rsq416y6t7wbODG+/b3mm x6A8NFQDmALYU80iCVzWA08KVmt4cNbbQSYo6fVtuviK7vouKT9/8jfzig4jhLlpi16I IQoGrntBSYENc6SwClUNs331/KHQufq/ZZs/Jd2vL7lXkcoVbfpdZSPlKZc9zRdoqznP IajyvNb8lm+qFKREBLsMqks4I4Qh6s9BDwjA9uOUgd1YuuOgaOa9sS9RgbODBtgAe/rl IN9j3aMor0+ImS1T1DxzpGtHNmEtuL0H6E2KEWzz8RXuE6dB/IcQa4HzZZzYt2pcnj9R PmIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=+zxM6DeKTMsz3MStf4P75OZ/c3rBu5g82Z+NI/KYdxo=; b=hK55AZ04aMvdN5hapns6Waor1YaeEW5tMNZKPFWw2h+abpt7sOJSaRuD3kFhhYT4LR BKvo7bv3yldokTBbt/MYbeNy8qVVxIdlm4E7z60Ud/H25xU5hshMIZzdS2UoCEwdjl4L LffGOLsDL1G5mZtNA1pDqetT3ZcqC2BoXz7ZbDhk5pERKW/YoY2winKKIok1CZSPB0gJ PPdeZkbMr6IpMAVU1x5BroZJY9phmZCVU6piYqNiJRtRihR1B45MCQ1r7ywAn62npReO Yu5gFExG0nAvdX6TaxAHHIwJs/zfF74Qm2Ycv67Jzny4S6FBzyok+Qk0Hsd08qadArck Ni8g== ARC-Authentication-Results: i=1; mx.google.com; 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 h6si199581ejo.288.2021.05.27.03.06.33; Thu, 27 May 2021 03:07:00 -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; 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 S236081AbhE0KGN convert rfc822-to-8bit (ORCPT + 99 others); Thu, 27 May 2021 06:06:13 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:52923 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236054AbhE0KGM (ORCPT ); Thu, 27 May 2021 06:06:12 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 21B77C0008; Thu, 27 May 2021 10:04:30 +0000 (UTC) Date: Thu, 27 May 2021 12:04:23 +0200 From: Miquel Raynal To: Pratyush Yadav Cc: , Mark Brown , Vignesh Raghavendra , Boris Brezillon , , Alexandre Torgue , , , , , Subject: Re: mtd: spinand: add spi nand mtd resume handler Message-ID: <20210527120423.7bf18966@xps13> In-Reply-To: <20210527100015.abxcroi23zyvcyzk@ti.com> References: <20210526153016.32653-1-patrice.chotard@foss.st.com> <20210527100015.abxcroi23zyvcyzk@ti.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pratyush, Pratyush Yadav wrote on Thu, 27 May 2021 15:30:17 +0530: > On 26/05/21 05:30PM, patrice.chotard@foss.st.com wrote: > > From: Christophe Kerello > > > > After power up, all SPI NAND's blocks are locked. Only read operations > > are allowed, write and erase operations are forbidden. > > The SPI NAND framework unlocks all the blocks during its initialization. > > > > During a standby low power, the memory is powered down, losing its > > configuration. > > During the resume, the QSPI driver state is restored but the SPI NAND > > framework does not reconfigured the memory. > > > > This patch adds spi nand mtd PM handlers for resume ops. > > SPI NAND resume op re-initializes SPI NAND flash to its probed state. > > > > Signed-off-by: Christophe Kerello > > Signed-off-by: Patrice Chotard > > --- > > drivers/mtd/nand/spi/core.c | 56 +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > > > diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c > > index 17f63f95f4a2..6abaf874eb3f 100644 > > --- a/drivers/mtd/nand/spi/core.c > > +++ b/drivers/mtd/nand/spi/core.c > > @@ -1074,6 +1074,61 @@ static int spinand_detect(struct spinand_device *spinand) > > return 0; > > } > > > > +static void spinand_mtd_resume(struct mtd_info *mtd) > > +{ > > + struct spinand_device *spinand = mtd_to_spinand(mtd); > > + struct nand_device *nand = mtd_to_nanddev(mtd); > > + struct device *dev = &spinand->spimem->spi->dev; > > + int ret, i; > > + > > + ret = spinand_reset_op(spinand); > > + if (ret) > > + return; > > + > > + ret = spinand_init_quad_enable(spinand); > > + if (ret) { > > + dev_err(dev, > > + "Failed to initialize the quad part (err = %d)\n", > > + ret); > > + return; > > + } > > + > > + ret = spinand_upd_cfg(spinand, CFG_OTP_ENABLE, 0); > > + if (ret) { > > + dev_err(dev, > > + "Failed to updtae the OTP (err = %d)\n", > > + ret); > > + return; > > + } > > Since you have reset the flash, this cache is invalid. You should reset > the cache and re-populate it before using it in any way. > > > + > > + ret = spinand_manufacturer_init(spinand); > > + if (ret) { > > + dev_err(dev, > > + "Failed to initialize the SPI NAND chip (err = %d)\n", > > + ret); > > + return; > > + } > > + > > + /* After power up, all blocks are locked, so unlock them here. */ > > + for (i = 0; i < nand->memorg.ntargets; i++) { > > + ret = spinand_select_target(spinand, i); > > + if (ret) { > > + dev_err(dev, > > + "Failed to select the target (err = %d)\n", > > + ret); > > + return; > > + } > > + > > + ret = spinand_lock_block(spinand, BL_ALL_UNLOCKED); > > + if (ret) { > > + dev_err(dev, > > + "Failed to unlock block (err = %d)\n", > > + ret); > > + return; > > + } > > + } > > +} > > + > > Most of these seem to be copied from spinand_init(). I think it is > better to create a common function that can be called from both > spinand_init() and spinand_mtd_resume(). This way when someone adds > something new to the init procedure, like support for some other modes, > they won't have to remember to update it in two places. Agreed, let's write a common helper for more than just the unlocking sequence (still in a separate patch). > > > static int spinand_init(struct spinand_device *spinand) > > { > > struct device *dev = &spinand->spimem->spi->dev; > > @@ -1167,6 +1222,7 @@ static int spinand_init(struct spinand_device *spinand) > > mtd->_block_isreserved = spinand_mtd_block_isreserved; > > mtd->_erase = spinand_mtd_erase; > > mtd->_max_bad_blocks = nanddev_mtd_max_bad_blocks; > > + mtd->_resume = spinand_mtd_resume; > > Is it possible that the userspace can use this mtd device before the > resume is finished? Is there a way to temporarily "pause" or unregister > an mtd device? I don't expect this to happen, I would expect the kernel to resume entirely before giving the hand to userspace, but I am not 100% sure of that neither. > > > > > if (nand->ecc.engine) { > > ret = mtd_ooblayout_count_freebytes(mtd); > Thanks, Miquèl