Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp877278pxj; Thu, 27 May 2021 13:51:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+lN5thErUOzlkyBZQrVZ5zLACX3UvR3tpuQ7nYyXsL43TaMKhPxn9JYrPoqO0dvTZ2Saa X-Received: by 2002:a50:fd9a:: with SMTP id o26mr6257501edt.76.1622148700916; Thu, 27 May 2021 13:51:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622148700; cv=none; d=google.com; s=arc-20160816; b=yVdKW5jZTAXRTWEVDrOJ9mTyU+dxnbA7ERC1JDIbYGC00R4VAwyeNAD5+5dgqBz9+C dmxlQq4fhsDMvhQTtxN4YIGA2rJ+EKhaj9PwmYytQjHn85Mof+9ofLmE8qKSxx3pLcG5 dlq4c4OSjKRnlrpBeFnTgdWoMWXma5CuUjlpFkTwzrGJ4jgcPSSRUo1kG3yyG43+Od7f AHJ7+VrwizEr5igURYwUOwDZpfWkVAkRNJf5lF478255obtcj26JCiAaHMHrYrTTEUj7 oW0M+x++UyoIUsjEI6SuA2c6iZfLTGvVclSkqWhEsW1UsxVeLcdOu72SARl/xXsRcEYr Q9Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=Vvo4lmC0J+8Th7Lx+/tE/cI6WkohGoJEOy5+1hxoZ54=; b=QknZmDyQDx32g4Ax821/cpwxNeZtSR0F7B4gZAW5QzZWXxeCyv898a8iFWlLZwrqQI YtJ49WxK5GGtz8IGARiS5rYAVeRmgIRA9Pay95ke/gjkb2WU8BI3u7+C/U2NuQUA2YcB VTb+ND6vTkJONHJBYmgwBciN7TYW1GgKrIstFIoNN2lPMsGVAxW3Ak7rXc9X/fWSnEKY h8bzlQIiwb0VqmhmxOyeA22vjca/wEpLMCWua1BtqWbkinidhLKyNRhNdortuMKvLf/N ld11Oz2HUROMKWqfx3ZEQbPdo60Nw2VkBu6nrUWjiZXzWD2U9eGpObkHXfpYoGdlhA3Y rpqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=2w7kU1wz; 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=NONE sp=NONE dis=NONE) header.from=foss.st.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p23si3595438edw.135.2021.05.27.13.51.17; Thu, 27 May 2021 13:51:40 -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=@foss.st.com header.s=selector1 header.b=2w7kU1wz; 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=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236633AbhE0NwK (ORCPT + 99 others); Thu, 27 May 2021 09:52:10 -0400 Received: from mx08-00178001.pphosted.com ([91.207.212.93]:39296 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S236580AbhE0NwK (ORCPT ); Thu, 27 May 2021 09:52:10 -0400 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14RDgLGR013480; Thu, 27 May 2021 15:50:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=Vvo4lmC0J+8Th7Lx+/tE/cI6WkohGoJEOy5+1hxoZ54=; b=2w7kU1wz6fEl5jbBTPmB5FhF0/iaP7K3N3mjGQ+m7HOIXNR0T1nhW6ytDEcYIdY9E5Bk ijMaU/XmQggmuR86nlIqgorOKd9tn1lKGvnRe1m1xENWs2DRbTrBfFyhpvdQ7KjpHKOh nodb//LT0fuTYVNz5RxGE3lIgLH3TsysHJOjWT8nBj52AOKNZeEuUIlkNtTseVUBp6q9 4POBk4pmR+xb6CXkcZk9ylgLCNj43XaFPQiI7j04WBFYdVKkxgA8mBmzcpPjNUt8Pt2y 11jbwWynch5DHZa08VDD4fHY0k15AKIRY9mRmvHLUJU/zsLEp0/E+V5sbbLS8tIMBufE uw== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 38t0fr49qf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 May 2021 15:50:26 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C4473100034; Thu, 27 May 2021 15:50:25 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag2node3.st.com [10.75.127.6]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id A73EA228134; Thu, 27 May 2021 15:50:25 +0200 (CEST) Received: from lmecxl0573.lme.st.com (10.75.127.46) by SFHDAG2NODE3.st.com (10.75.127.6) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 27 May 2021 15:50:24 +0200 Subject: Re: mtd: spinand: add spi nand mtd resume handler To: Pratyush Yadav CC: Mark Brown , Miquel Raynal , Vignesh Raghavendra , Boris Brezillon , , Alexandre Torgue , , , , , References: <20210526153016.32653-1-patrice.chotard@foss.st.com> <20210527100015.abxcroi23zyvcyzk@ti.com> From: Patrice CHOTARD Message-ID: <3baf8f02-f290-91d1-af56-62181651c61a@foss.st.com> Date: Thu, 27 May 2021 15:50:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210527100015.abxcroi23zyvcyzk@ti.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.75.127.46] X-ClientProxiedBy: SFHDAG1NODE1.st.com (10.75.127.1) To SFHDAG2NODE3.st.com (10.75.127.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-05-27_06:2021-05-26,2021-05-27 signatures=0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pratyush On 5/27/21 12:00 PM, Pratyush Yadav wrote: > 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. I got your point, i will take it in account in v3 (v2 has already been send but need rework) > >> + >> + 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. Agree, it was already part of the v2 > >> 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? Honestly, i don't know. Thanks Patrice > >> >> if (nand->ecc.engine) { >> ret = mtd_ooblayout_count_freebytes(mtd); >