All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Michal Simek <monstr@monstr.eu>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Naga Sureshkumar Relli <nagasure@xilinx.com>
Subject: Re: [PATCH v2 03/11] mtd: rawnand: Rename a NAND chip option
Date: Wed, 29 Apr 2020 18:32:31 +0200	[thread overview]
Message-ID: <20200429183231.1a3607c1@collabora.com> (raw)
In-Reply-To: <20200429182200.4240303d@xps13>

On Wed, 29 Apr 2020 18:22:00 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hi Boris,
> 
> Boris Brezillon <boris.brezillon@collabora.com> wrote on Wed, 29 Apr
> 2020 18:08:16 +0200:
> 
> > On Wed, 29 Apr 2020 17:55:32 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >   
> > > NAND controller drivers can set the NAND_USE_BOUNCE_BUFFER flag to a
> > > chip 'option' field. With this flag, the core is responsible of
> > > providing DMA-able buffers.
> > > 
> > > The current behavior is to not force the use of a bounce buffer when
> > > the core thinks this is not needed. So in the end the name is a bit
> > > misleading, because in theory we will always have a DMA buffer but in
> > > practice it will not always be a bounce buffer.
> > > 
> > > Rename this flag NAND_USE_DMA_BUFFER to be more accurate.    
> > 
> > I still think this one should be named NAND_CONTROLLER_USES_DMA.  
> 
> Actually I want to rework all the flags and prefix them with
> NAND_CONTROLLER, that's why I am keeping the NAND_ prefix. I can change
> the _USE_DMA_BUFFER into _USES_DMA though.

Ack on NAND_USES_DMA.

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

  reply	other threads:[~2020-04-29 16:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 15:55 [PATCH v2 00/11] Supporting restricted NAND controllers Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 01/11] mtd: rawnand: Translate obscure bitfields into readable macros Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 02/11] mtd: rawnand: Reorder the nand_chip->options flags Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 03/11] mtd: rawnand: Rename a NAND chip option Miquel Raynal
2020-04-29 16:08   ` Boris Brezillon
2020-04-29 16:22     ` Miquel Raynal
2020-04-29 16:32       ` Boris Brezillon [this message]
2020-04-29 16:36         ` Boris Brezillon
2020-04-29 16:54           ` Miquel Raynal
2020-04-29 18:55             ` Boris Brezillon
2020-04-29 15:55 ` [PATCH v2 04/11] mtd: rawnand: Fix comments about the use of bufpoi Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 05/11] mtd: rawnand: Rename the use_bufpoi variables Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 06/11] mtd: rawnand: Avoid indirect access to ->data_buf() Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 07/11] mtd: rawnand: onfi: Adapt the parameter page read to constraint controllers Miquel Raynal
2020-04-29 16:09   ` Boris Brezillon
2020-05-02  8:12   ` Boris Brezillon
2020-05-04  8:16     ` Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 08/11] mtd: rawnand: jedec: " Miquel Raynal
2020-04-29 16:04   ` Boris Brezillon
2020-04-29 16:23     ` Miquel Raynal
2020-05-03 19:06     ` Miquel Raynal
2020-05-03 19:44       ` Boris Brezillon
2020-05-04  8:02         ` Miquel Raynal
2020-04-29 15:55 ` [PATCH v2 09/11] mtd: rawnand: Expose monolithic read/write_page_raw() helpers Miquel Raynal
2020-04-29 16:15   ` Boris Brezillon
2020-04-29 16:26     ` Miquel Raynal
2020-04-29 16:31       ` Boris Brezillon
2020-04-29 16:52         ` Miquel Raynal
2020-04-29 19:03           ` Boris Brezillon
2020-04-29 15:55 ` [PATCH v2 10/11] mtd: rawnand: Allow controllers to overload soft ECC hooks Miquel Raynal
2020-04-29 16:15   ` Boris Brezillon
2020-04-29 15:55 ` [PATCH v2 11/11] mtd: rawnand: micron: Allow controllers to overload raw accessors Miquel Raynal
2020-04-29 16:16   ` Boris Brezillon

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=20200429183231.1a3607c1@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=monstr@monstr.eu \
    --cc=nagasure@xilinx.com \
    --cc=richard@nod.at \
    --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.