All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
	dwmw2@infradead.org
Subject: Re: [PATCH 2/5] mtd: nand: Propagate mtd_device_unregister() return value in tear down
Date: Thu, 7 Jul 2016 20:58:32 +0200	[thread overview]
Message-ID: <20160707205832.2065efad@bbrezillon> (raw)
In-Reply-To: <577E9F84.3000108@nod.at>

On Thu, 7 Jul 2016 20:29:24 +0200
Richard Weinberger <richard@nod.at> wrote:

> Boris,
> 
> Am 06.07.2016 um 15:34 schrieb Boris Brezillon:
> >>  /**
> >> - * nand_release - [NAND Interface] Free resources held by the NAND device
> >> + * __nand_release - [NAND Interface] Free resources held by the NAND device
> >>   * @mtd: MTD device structure
> >>   */
> >> -void nand_release(struct mtd_info *mtd)
> >> +int __nand_release(struct mtd_info *mtd)  
> > 
> > Can we find a better name? nand_release_safe()?  
> 
> Sure. Let's pick nand_release_safe().
> 
> >>  {
> >> +	int ret;
> >>  	struct nand_chip *chip = mtd_to_nand(mtd);
> >>  
> >> +	ret = mtd_device_unregister(mtd);
> >> +	if (ret)
> >> +		return ret;
> >> +  
> > 
> > The question is, should we unregister the MTD device in nand_release().
> > It feels a bit odd to have nand_scan_xxx() functions only doing the
> > nand_chip initialization and letting the NAND controller driver
> > register the MTD device, and have nand_release() unregister the MTD
> > device for us.
> > 
> > Maybe we should export a nand_cleanup() function that would just
> > release nand_chip resources and let NAND controller drivers that
> > really care about mtd_device_unregister() return code call it
> > themselves before calling nand_cleanup() (instead of calling
> > nand_release()).  
> 
> You mean renaming nand_release() to nand_cleanup() and the driver
> has to issue mtd_device_unregister() itself before it is allowed to
> do nand_cleanup(). Yes, that is also an option.
> The only downside is that we have to touch a lot of drivers then.
> But the conversion should be almost trivial.

No, I meant adding nand_cleanup() and then patching nand_release() to
first calling mtd_device_unregister() and then nand_cleanup(). This way
you get rid of __nand_release() and use mtd_device_unregister() +
nand_cleanup() in drivers that really care about
mtd_device_unregister() return code.

  reply	other threads:[~2016-07-07 18:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04 22:06 MTD life cycle fixes Richard Weinberger
2016-07-04 22:06 ` [PATCH 1/5] mtdpart: Propagate _get/put_device() Richard Weinberger
2016-07-04 22:06 ` [PATCH 2/5] mtd: nand: Propagate mtd_device_unregister() return value in tear down Richard Weinberger
2016-07-06 13:34   ` Boris Brezillon
2016-07-07 18:29     ` Richard Weinberger
2016-07-07 18:58       ` Boris Brezillon [this message]
2016-07-04 22:06 ` [PATCH 3/5] mtd: Don't unconditionally unregister reboot notifier Richard Weinberger
2016-09-28 20:30   ` Brian Norris
2016-07-04 22:06 ` [PATCH 4/5] mtd: Don't unconditionally execute remove notifiers Richard Weinberger
2016-07-07 14:59   ` Boris Brezillon
2016-09-28 20:31   ` Brian Norris
2016-07-04 22:06 ` [PATCH 5/5] mtd: Don't print a scary message when trying to remove a busy MTD Richard Weinberger
2016-07-07 14:58   ` Boris Brezillon
2016-07-07 18:48     ` Richard Weinberger
2016-07-07 18:53       ` Boris Brezillon
2016-07-07 18:56         ` Richard Weinberger

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=20160707205832.2065efad@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.