All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, Michal Simek <monstr@monstr.eu>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mtd@lists.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Naga Sureshkumar Relli <nagasure@xilinx.com>
Subject: Re: [PATCH v3 7/8] mtd: rawnand: arasan: Add new Arasan NAND controller
Date: Thu, 7 May 2020 17:53:01 +0200	[thread overview]
Message-ID: <20200507175301.7affb8f7@xps13> (raw)
In-Reply-To: <20200507172453.15a03574@collabora.com>

Hi Boris,

Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 7 May
2020 17:24:53 +0200:

> On Thu, 7 May 2020 17:13:11 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> > Hi Boris,
> > 
> > Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 7 May
> > 2020 14:11:03 +0200:
> >   
> > > On Thu,  7 May 2020 13:00:33 +0200
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > 
> > >     
> > > > +
> > > > +static void anfc_chips_cleanup(struct arasan_nfc *nfc)
> > > > +{
> > > > +	struct anand *anand, *tmp;
> > > > +
> > > > +	list_for_each_entry_safe(anand, tmp, &nfc->chips, node) {
> > > > +		nand_release(&anand->chip);      
> > > 
> > > 		ret = mtd_device_unregister(nand_to_mtd(&anand->chip));
> > > 		WARN_ON(ret);
> > > 		nand_cleanup(&anand->chip);
> > > 
> > > Or maybe add this WARN_ON() to nand_release() so we don't have to ask
> > > people to use mtd_device_unregister() + nand_cleanup().    
> > 
> > I don't get your point here? I'm not against adding a warn_on between
> > both functions but it's not related to this driver?  
> 
> We've asked people to not call nand_release() but instead call
> mtd_device_unregister()+nand_cleanup(), which is not done here. My
> point is, if even us can't get it right, maybe it's a sign we should
> instead patch nand_release() to do the right thing.

It's in my todo-list, yes. What about just dropping nand_release
entirely? So that nand_scan_tail as its nand cleanup and
mtd_device_register as its mtd_device_unregister and everything will be
much clearer?


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>, <devicetree@vger.kernel.org>,
	Richard Weinberger <richard@nod.at>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	<linux-mtd@lists.infradead.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Michal Simek <monstr@monstr.eu>,
	Naga Sureshkumar Relli <nagasure@xilinx.com>
Subject: Re: [PATCH v3 7/8] mtd: rawnand: arasan: Add new Arasan NAND controller
Date: Thu, 7 May 2020 17:53:01 +0200	[thread overview]
Message-ID: <20200507175301.7affb8f7@xps13> (raw)
In-Reply-To: <20200507172453.15a03574@collabora.com>

Hi Boris,

Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 7 May
2020 17:24:53 +0200:

> On Thu, 7 May 2020 17:13:11 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> > Hi Boris,
> > 
> > Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 7 May
> > 2020 14:11:03 +0200:
> >   
> > > On Thu,  7 May 2020 13:00:33 +0200
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > 
> > >     
> > > > +
> > > > +static void anfc_chips_cleanup(struct arasan_nfc *nfc)
> > > > +{
> > > > +	struct anand *anand, *tmp;
> > > > +
> > > > +	list_for_each_entry_safe(anand, tmp, &nfc->chips, node) {
> > > > +		nand_release(&anand->chip);      
> > > 
> > > 		ret = mtd_device_unregister(nand_to_mtd(&anand->chip));
> > > 		WARN_ON(ret);
> > > 		nand_cleanup(&anand->chip);
> > > 
> > > Or maybe add this WARN_ON() to nand_release() so we don't have to ask
> > > people to use mtd_device_unregister() + nand_cleanup().    
> > 
> > I don't get your point here? I'm not against adding a warn_on between
> > both functions but it's not related to this driver?  
> 
> We've asked people to not call nand_release() but instead call
> mtd_device_unregister()+nand_cleanup(), which is not done here. My
> point is, if even us can't get it right, maybe it's a sign we should
> instead patch nand_release() to do the right thing.

It's in my todo-list, yes. What about just dropping nand_release
entirely? So that nand_scan_tail as its nand cleanup and
mtd_device_register as its mtd_device_unregister and everything will be
much clearer?


  reply	other threads:[~2020-05-07 15:53 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 11:00 [PATCH v3 0/8] New Arasan NAND controller driver Miquel Raynal
2020-05-07 11:00 ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 1/8] lib/bch: Rework a little bit the exported function names Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 11:48   ` Boris Brezillon
2020-05-07 11:48     ` Boris Brezillon
2020-05-07 14:11     ` Miquel Raynal
2020-05-07 14:11       ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 2/8] lib/bch: Allow easy bit swapping Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 11:43   ` Boris Brezillon
2020-05-07 11:43     ` Boris Brezillon
2020-05-07 14:09     ` Miquel Raynal
2020-05-07 14:09       ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 3/8] mtd: rawnand: Ensure the number of bitflips is consistent Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 4/8] mtd: rawnand: Add nand_extract_bits() Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 11:49   ` Boris Brezillon
2020-05-07 11:49     ` Boris Brezillon
2020-05-07 14:12     ` Miquel Raynal
2020-05-07 14:12       ` Miquel Raynal
2020-05-08 17:20       ` Miquel Raynal
2020-05-08 17:20         ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 5/8] MAINTAINERS: Add Arasan NAND controller and bindings Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 11:50   ` Boris Brezillon
2020-05-07 11:50     ` Boris Brezillon
2020-05-07 11:00 ` [PATCH v3 6/8] dt-bindings: mtd: Document ARASAN NAND bindings Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 7/8] mtd: rawnand: arasan: Add new Arasan NAND controller Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 12:11   ` Boris Brezillon
2020-05-07 12:11     ` Boris Brezillon
2020-05-07 15:13     ` Miquel Raynal
2020-05-07 15:13       ` Miquel Raynal
2020-05-07 15:24       ` Boris Brezillon
2020-05-07 15:24         ` Boris Brezillon
2020-05-07 15:53         ` Miquel Raynal [this message]
2020-05-07 15:53           ` Miquel Raynal
2020-05-07 16:12           ` Boris Brezillon
2020-05-07 16:12             ` Boris Brezillon
2020-05-07 12:51   ` Boris Brezillon
2020-05-07 12:51     ` Boris Brezillon
2020-05-07 15:45     ` Miquel Raynal
2020-05-07 15:45       ` Miquel Raynal
2020-05-07 16:11       ` Boris Brezillon
2020-05-07 16:11         ` Boris Brezillon
2020-05-07 16:19         ` Miquel Raynal
2020-05-07 16:19           ` Miquel Raynal
2020-05-07 19:13     ` Miquel Raynal
2020-05-07 19:13       ` Miquel Raynal
2020-05-07 11:00 ` [PATCH v3 8/8] mtd: rawnand: arasan: Support the hardware BCH ECC engine Miquel Raynal
2020-05-07 11:00   ` Miquel Raynal
2020-05-07 12:03   ` Boris Brezillon
2020-05-07 12:03     ` Boris Brezillon
2020-05-07 15:09     ` Miquel Raynal
2020-05-07 15:09       ` 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=20200507175301.7affb8f7@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=boris.brezillon@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=monstr@monstr.eu \
    --cc=nagasure@xilinx.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzoni@bootlin.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 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.