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 35F50C433EF for ; Wed, 20 Oct 2021 07:23:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 19D1B610FF for ; Wed, 20 Oct 2021 07:23:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229959AbhJTHZs convert rfc822-to-8bit (ORCPT ); Wed, 20 Oct 2021 03:25:48 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:44475 "EHLO relay7-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbhJTHZr (ORCPT ); Wed, 20 Oct 2021 03:25:47 -0400 Received: (Authenticated sender: miquel.raynal@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 4ACDB2000F; Wed, 20 Oct 2021 07:23:32 +0000 (UTC) Date: Wed, 20 Oct 2021 09:23:31 +0200 From: Miquel Raynal To: Sean Nyekjaer Cc: Boris Brezillon , Richard Weinberger , Vignesh Raghavendra , Boris Brezillon , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] mtd: core: protect access to mtd devices while in suspend Message-ID: <20211020092331.68e46e16@xps13> In-Reply-To: <20211020071235.in3omswo2jqrahrd@skn-laptop> References: <20211011115253.38497-1-sean@geanix.com> <20211011160546.707b737b@collabora.com> <20211015082206.244a2316@xps13> <20211019180800.3v7emokse6lkpjvk@skn-laptop> <20211020085250.030ef244@collabora.com> <20211020090058.58af1087@collabora.com> <20211020071235.in3omswo2jqrahrd@skn-laptop> 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 Sean, sean@geanix.com wrote on Wed, 20 Oct 2021 09:12:35 +0200: > On Wed, Oct 20, 2021 at 09:00:58AM +0200, Boris Brezillon wrote: > > On Wed, 20 Oct 2021 08:52:50 +0200 > > Boris Brezillon wrote: > > > > [ ... ] > > > > > > > > Hi Boris and Miquel, > > > > > > > > gpmi-nand.c sets NAND_SKIP_BBTSCAN so we won't get there and populate > > > > suspend resume hooks :( > > > > Guess there is other drivers that does the same thing... > > > > Actually, this version is even cleaner: > > > > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c > > index 3d6c6e880520..98c39b7f6279 100644 > > --- a/drivers/mtd/nand/raw/nand_base.c > > +++ b/drivers/mtd/nand/raw/nand_base.c > > @@ -6222,8 +6222,6 @@ static int nand_scan_tail(struct nand_chip *chip) > > mtd->_sync = nand_sync; > > mtd->_lock = nand_lock; > > mtd->_unlock = nand_unlock; > > - mtd->_suspend = nand_suspend; > > - mtd->_resume = nand_resume; > > mtd->_reboot = nand_shutdown; > > mtd->_block_isreserved = nand_block_isreserved; > > mtd->_block_isbad = nand_block_isbad; > > @@ -6261,14 +6259,20 @@ static int nand_scan_tail(struct nand_chip *chip) > > goto err_free_interface_config; > > > > /* Check, if we should skip the bad block table scan */ > > - if (chip->options & NAND_SKIP_BBTSCAN) > > - return 0; > > - > > - /* Build bad block table */ > > - ret = nand_create_bbt(chip); > > - if (ret) > > - goto err_free_secure_regions; > > + if (chip->options & NAND_SKIP_BBTSCAN) { > > + /* Build bad block table */ > > + ret = nand_create_bbt(chip); > > + if (ret) > > + goto err_free_secure_regions; > > + } > > > > + /* > > + * Populate the suspend/resume hooks after the BBT has been scanned to > > + * avoid using the suspend lock and resume waitqueue which are only > > + * initialized when mtd_device_register() is called. > > + */ > > + mtd->_suspend = nand_suspend; > > + mtd->_resume = nand_resume; > > return 0; > > > > err_free_secure_regions: > > Why is the gpmi-nand.c and other drivers set NAND_SKIP_BBTSCAN and then > call nand_create_bbt() directly? > > To me it looks like legacy leftover... It is... 885d71e5838f ("mtd: gpmi: fix the NULL pointer") added this flag to avoid a NULL pointer dereference on chip->buffer->databuf on mx23, which IIRC does not exist anymore. I believe we could get rid of it. But anyway, I like the "cleanup" proposed by Boris so IMHO you can add these two patches to the series. Thanks, Miquèl