public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Sean Nyekjaer <sean@geanix.com>,
	linux-kernel@vger.kernel.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	linux-mtd@lists.infradead.org
Subject: Re: [PATCH v5 3/4] mtd: core: protect access to MTD devices while in suspend
Date: Mon, 13 Dec 2021 10:28:01 +0100	[thread overview]
Message-ID: <20211213102801.569b50b1@collabora.com> (raw)
In-Reply-To: <20211213101025.42c27b43@xps13>

On Mon, 13 Dec 2021 10:10:25 +0100
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hi Sean,
> 
> sean@geanix.com wrote on Fri, 10 Dec 2021 14:25:35 +0100:
> 
> > On Thu, Dec 09, 2021 at 03:28:11PM +0100, Miquel Raynal wrote:  
> > > Hi Sean,
> > > 
> > > sean@geanix.com wrote on Thu, 9 Dec 2021 15:07:21 +0100:
> > >     
> > > > On Fri, Dec 03, 2021 at 02:39:58PM +0100, Miquel Raynal wrote:    
> > > > > Hello,
> > > > >       
> > > > > > > Fine by me, lets drop this series.      
> > > > > 
> > > > > FYI I've dropped the entire series from mtd/next. I'm waiting for the
> > > > > fix discussed below (without abusing the chip mutex ;-) ).      
> > > > 
> > > > Cool, looking forward to test a patch series :)    
> > > 
> > > Test? You mean "write"? :)
> > > 
> > > Cheers,
> > > Miquèl    
> > 
> > Hi Miquel,
> > 
> > Should we us a atomic for the suspended variable?  
> 
> I haven't thought about it extensively, an atomic variable sound fine
> but I am definitely not a locking expert...

No need to use an atomic if the variable is already protected by a lock
when accessed, and this seems to be case.

> 
> > 
> > /Sean
> > 
> > diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> > index b3a9bc08b4bb..eb4ec9a42d49 100644
> > --- a/drivers/mtd/nand/raw/nand_base.c
> > +++ b/drivers/mtd/nand/raw/nand_base.c
> > @@ -338,16 +338,19 @@ static int nand_isbad_bbm(struct nand_chip *chip, loff_t ofs)
> >   *
> >   * Return: -EBUSY if the chip has been suspended, 0 otherwise

You need to fix the documentation and make it clear that the caller
will be blocked if the chip is suspended.

> >   */
> > -static int nand_get_device(struct nand_chip *chip)
> > +static void nand_get_device(struct nand_chip *chip)
> >  {
> > -	mutex_lock(&chip->lock);
> > -	if (chip->suspended) {
> > +	/* Wait until the device is resumed. */
> > +	while (1) {
> > +		mutex_lock(&chip->lock);
> > +		if (!chip->suspended) {
> > +			mutex_lock(&chip->controller->lock);
> > +			return;
> > +		}
> >  		mutex_unlock(&chip->lock);
> > -		return -EBUSY;
> > -	}
> > -	mutex_lock(&chip->controller->lock);
> >  
> > -	return 0;
> > +		wait_event(chip->resume_wq, !chip->suspended);
> > +	}
> >  }
> >  
> >  /**
> > @@ -576,9 +579,7 @@ static int nand_block_markbad_lowlevel(struct nand_chip *chip, loff_t ofs)
> >  		nand_erase_nand(chip, &einfo, 0);
> >  
> >  		/* Write bad block marker to OOB */
> > -		ret = nand_get_device(chip);
> > -		if (ret)
> > -			return ret;
> > +		nand_get_device(chip);
> >  
> >  		ret = nand_markbad_bbm(chip, ofs);
> >  		nand_release_device(chip);
> > @@ -3759,9 +3760,7 @@ static int nand_read_oob(struct mtd_info *mtd, loff_t from,
> >  	    ops->mode != MTD_OPS_RAW)
> >  		return -ENOTSUPP;
> >  
> > -	ret = nand_get_device(chip);
> > -	if (ret)
> > -		return ret;
> > +	nand_get_device(chip);
> >  
> >  	if (!ops->datbuf)
> >  		ret = nand_do_read_oob(chip, from, ops);
> > @@ -4352,9 +4351,7 @@ static int nand_write_oob(struct mtd_info *mtd, loff_t to,
> >  
> >  	ops->retlen = 0;
> >  
> > -	ret = nand_get_device(chip);
> > -	if (ret)
> > -		return ret;
> > +	nand_get_device(chip);
> >  
> >  	switch (ops->mode) {
> >  	case MTD_OPS_PLACE_OOB:
> > @@ -4414,9 +4411,7 @@ int nand_erase_nand(struct nand_chip *chip, struct erase_info *instr,
> >  		return -EIO;
> >  
> >  	/* Grab the lock and see if the device is available */
> > -	ret = nand_get_device(chip);
> > -	if (ret)
> > -		return ret;
> > +	nand_get_device(chip);
> >  
> >  	/* Shift to get first page */
> >  	page = (int)(instr->addr >> chip->page_shift);
> > @@ -4503,7 +4498,7 @@ static void nand_sync(struct mtd_info *mtd)
> >  	pr_debug("%s: called\n", __func__);
> >  
> >  	/* Grab the lock and see if the device is available */
> > -	WARN_ON(nand_get_device(chip));
> > +	nand_get_device(chip);
> >  	/* Release it and go back */
> >  	nand_release_device(chip);
> >  }
> > @@ -4520,9 +4515,7 @@ static int nand_block_isbad(struct mtd_info *mtd, loff_t offs)
> >  	int ret;
> >  
> >  	/* Select the NAND device */
> > -	ret = nand_get_device(chip);
> > -	if (ret)
> > -		return ret;
> > +	nand_get_device(chip);
> >  
> >  	nand_select_target(chip, chipnr);
> >  
> > @@ -4593,6 +4586,8 @@ static void nand_resume(struct mtd_info *mtd)
> >  			__func__);
> >  	}
> >  	mutex_unlock(&chip->lock);
> > +
> > +	wake_up_all(&chip->resume_wq);
> >  }
> >  
> >  /**
> > @@ -5370,6 +5365,7 @@ static int nand_scan_ident(struct nand_chip *chip, unsigned int maxchips,
> >  	chip->cur_cs = -1;
> >  
> >  	mutex_init(&chip->lock);
> > +	init_waitqueue_head(&chip->resume_wq);
> >  
> >  	/* Enforce the right timings for reset/detection */
> >  	chip->current_interface_config = nand_get_reset_interface_config();
> > diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> > index b2f9dd3cbd69..248054560581 100644
> > --- a/include/linux/mtd/rawnand.h
> > +++ b/include/linux/mtd/rawnand.h
> > @@ -1294,6 +1294,7 @@ struct nand_chip {
> >  	/* Internals */
> >  	struct mutex lock;
> >  	unsigned int suspended : 1;
> > +	wait_queue_head_t resume_wq;
> >  	int cur_cs;
> >  	int read_retries;
> >  	struct nand_secure_region *secure_regions;  
> 
> 
> Thanks,
> Miquèl


  reply	other threads:[~2021-12-13  9:28 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-02 11:02 [PATCH v5 0/4] mtd: core: protect access to mtd devices while in suspend Sean Nyekjaer
2021-11-02 11:02 ` [PATCH v5 1/4] mtd: rawnand: nand_bbt: hide suspend/resume hooks while scanning bbt Sean Nyekjaer
2021-11-19 18:35   ` Miquel Raynal
2021-11-02 11:02 ` [PATCH v5 2/4] mtd: mtdconcat: don't use mtd_{suspend,resume}() Sean Nyekjaer
2021-11-19 18:35   ` Miquel Raynal
2021-11-02 11:02 ` [PATCH v5 3/4] mtd: core: protect access to MTD devices while in suspend Sean Nyekjaer
2021-11-19 18:35   ` Miquel Raynal
2021-11-23 12:03   ` Marek Szyprowski
2021-11-23 12:50     ` Sean Nyekjaer
2021-11-23 13:07       ` Boris Brezillon
2021-11-29  9:19         ` Miquel Raynal
2021-11-29  9:41           ` Sean Nyekjaer
2021-11-29 11:17             ` Marek Szyprowski
2021-11-30 12:41               ` Sean Nyekjaer
2021-11-30 13:15                 ` Boris Brezillon
2021-11-30 13:29                   ` Sean Nyekjaer
2021-11-30 13:37                     ` Boris Brezillon
2021-12-03 13:39                       ` Miquel Raynal
2021-12-09 14:07                         ` Sean Nyekjaer
2021-12-09 14:28                           ` Miquel Raynal
2021-12-10 13:25                             ` Sean Nyekjaer
2021-12-13  9:10                               ` Miquel Raynal
2021-12-13  9:28                                 ` Boris Brezillon [this message]
2021-12-13  9:33                                   ` Miquel Raynal
2021-12-13  9:53                                     ` Boris Brezillon
2021-12-13 10:50                                       ` Sean Nyekjaer
2021-12-13 11:06                                         ` Boris Brezillon
2021-11-02 11:02 ` [PATCH v5 4/4] mtd: rawnand: remove suspended check Sean Nyekjaer
2021-11-19 18:35   ` Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211213102801.569b50b1@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=bbrezillon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=m.szyprowski@samsung.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sean@geanix.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox