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 05/10] mtd: rawnand: Rename the use_bufpoi variables
Date: Tue, 28 Apr 2020 11:11:55 +0200 [thread overview]
Message-ID: <20200428111155.57b6c43d@collabora.com> (raw)
In-Reply-To: <20200428110501.2caafbd9@xps13>
On Tue, 28 Apr 2020 11:05:01 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Hi Boris,
>
> Boris Brezillon <boris.brezillon@collabora.com> wrote on Sat, 25 Apr
> 2020 10:44:40 +0200:
>
> > On Fri, 24 Apr 2020 19:36:26 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > Both in nand_do_read_ops() and nand_do_write_ops() there is a boolean
> > > called use_bufpoi which is set to true in case of unaligned request or
> > > when there is a need for a DMA-able buffer. It basically means "use a
> > > bounce buffer".
> > >
> > > Depending on the value of use_bufpoi, the bufpoi variable is always
> > > used and will either point to the original buffer or to the nand_chip
> > > structure "internal data buffer" (this buffer is allocated with
> > > kmalloc() on purpose so that it will be DMA-compliant).
> > >
> > > In all cases bufpoi is used so the boolean name is misleading. Rename
> > > use_bufpoi to be use_bouce_buf to be more accurate.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >
> > Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> >
> > I wonder if we shouldn't find a better name for bufpoi too. Not sure
> > what the poi means here (pointer?). So maybe just rename those into
> > read_buf, write_buf (since buf seems to be declared already).
>
> My first patch also renamed bufpoi.
>
> Actually I read it like "buf pointer" and it makes sense and is used
> all across nand_base.c so I decided to let it as-is for now.
Fair enough.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-04-28 9:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 17:36 [PATCH 00/10] Supporting restricted NAND controllers Miquel Raynal
2020-04-24 17:36 ` [PATCH 01/10] mtd: rawnand: Translate obscure bitfields into readable macros Miquel Raynal
2020-04-25 8:33 ` Boris Brezillon
2020-04-28 9:46 ` Miquel Raynal
2020-04-24 17:36 ` [PATCH 02/10] mtd: rawnand: Reorder the nand_chip->options flags Miquel Raynal
2020-04-25 8:36 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 03/10] mtd: rawnand: Rename a NAND chip option Miquel Raynal
2020-04-25 8:39 ` Boris Brezillon
2020-04-28 12:05 ` Miquel Raynal
2020-04-24 17:36 ` [PATCH 04/10] mtd: rawnand: Fix comments about the use of bufpoi Miquel Raynal
2020-04-25 8:40 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 05/10] mtd: rawnand: Rename the use_bufpoi variables Miquel Raynal
2020-04-25 8:44 ` Boris Brezillon
2020-04-28 9:05 ` Miquel Raynal
2020-04-28 9:11 ` Boris Brezillon [this message]
2020-04-24 17:36 ` [PATCH 06/10] mtd: rawnand: Avoid indirect access to ->data_buf() Miquel Raynal
2020-04-25 8:45 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 07/10] mtd: rawnand: Help supporting controllers that are not able to split operations Miquel Raynal
2020-04-25 9:11 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 08/10] mtd: rawnand: onfi: Add an alternative parameter page read Miquel Raynal
2020-04-24 17:36 ` [PATCH 09/10] mtd: rawnand: jedec: " Miquel Raynal
2020-04-24 17:36 ` [PATCH 10/10] mtd: rawnand: Fallback on easier operations when needed 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=20200428111155.57b6c43d@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.