From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Lior Amsalem <alior@marvell.com>,
Jason Cooper <jason@lakedaemon.net>,
Tawfik Bayouk <tawfik@marvell.com>,
Artem Bityutskiy <dedekind1@gmail.com>,
Daniel Mack <zonque@gmail.com>,
linux-mtd@lists.infradead.org,
Gregory Clement <gregory.clement@free-electrons.com>,
Willy Tarreau <w@1wt.eu>
Subject: Re: [PATCH 01/21] mtd: nand: pxa3xx: Allocate data buffer on detected flash size
Date: Mon, 30 Sep 2013 09:37:57 -0300 [thread overview]
Message-ID: <20130930123756.GB2417@localhost> (raw)
In-Reply-To: <20130926201032.GL23337@ld-irv-0074.broadcom.com>
On Thu, Sep 26, 2013 at 01:10:32PM -0700, Brian Norris wrote:
> On Thu, Sep 19, 2013 at 01:01:25PM -0300, Ezequiel Garcia wrote:
> > This commit replaces the currently hardcoded buffer size, by a
> > dynamic detection scheme. First a small 256 bytes buffer is allocated
> > so the device can be detected (using READID and friends commands).
> >
> > After detection, this buffer is released and a new buffer is allocated
> > to acommodate the page size plus out-of-band size.
> >
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>
> This is the patch that breaks Daniel's DMA setup, right? It looks a bit
> off.
What do you mean by 'a bit off'?
> I'll wait to comment on it much until v2.
>
Ok... let me re-work it then and prepare the v2.
> BTW, there is a similar issue with at least one other driver (denali.c,
> maybe others) where the driver uses some hard assumptions about the
> maximum page/OOB sizes (NAND_MAX_PAGESIZE and NAND_MAX_OOBSIZE). This is
> kind of ugly and not very sustainable/maintainable, since these
> dimensions keep increasing. I appreciate your effort to avoid simply
> kludging in a larger MAX_BUFF_SIZE :) I had similar plans for the other
> drivers, but I don't know if we'll have much testing opportunities for
> the ancient ones...
>
> Also, it seems like your driver has a few potential leaks right now. If
> alloc_nand_resource() succeeds but pxa3xx_nand_probe() later fails
> (e.g., in pxa3xx_nand_scan()), you don't clean up after yourself. You
> should address this soon, even if not in this patch series.
>
Hm.. are you sure about that? AFAICS, there's no leak at all.
If alloc_nand_resource() succeeds, the only leakable resources allocated
are the ones allocated at pxa3xx_nand_init_buff() and the NAND base
stuff.
If pxa3xx_nand_probe() later fails to complete, it calls pxa3xx_nand_remove()
in this part:
if (!probe_success) {
pxa3xx_nand_remove(pdev);
return -ENODEV;
}
Which takes care of cleaning both the buffers and the NAND base stuff.
Or am I missing something?
Feel free to ask more questions and thanks a lot for the feedback.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-09-30 12:38 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 16:01 [PATCH 00/21] Armada 370/XP NAND support Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 01/21] mtd: nand: pxa3xx: Allocate data buffer on detected flash size Ezequiel Garcia
2013-09-26 20:10 ` Brian Norris
2013-09-30 12:37 ` Ezequiel Garcia [this message]
2013-10-02 21:14 ` Brian Norris
2013-09-19 16:01 ` [PATCH 02/21] mtd: nand: pxa3xx: Disable OOB on arbitrary length commands Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 03/21] mtd: nand: pxa3xx: Use a completion to signal device ready Ezequiel Garcia
2013-10-02 21:56 ` Brian Norris
2013-10-04 18:54 ` Ezequiel Garcia
2013-10-16 20:23 ` Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 04/21] mtd: nand: pxa3xx: Add bad block handling Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 05/21] mtd: nand: pxa3xx: Add driver-specific ECC BCH support Ezequiel Garcia
2013-10-03 0:24 ` Brian Norris
2013-10-04 19:49 ` Ezequiel Garcia
2013-10-05 0:27 ` Brian Norris
2013-10-17 22:27 ` Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 06/21] mtd: nand: pxa3xx: Configure detected pages-per-block Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 07/21] mtd: nand: pxa3xx: Clear cmd buffer #3 (NDCB3) on command start Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 08/21] mtd: nand: pxa3xx: Make config menu show supported platforms Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 09/21] mtd: nand: pxa3xx: Split FIFO size from to-be-read FIFO count Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 10/21] mtd: nand: pxa3xx: Replace host->page_size by mtd->writesize Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 11/21] mtd: nand: pxa3xx: Add helper function to set page address Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 12/21] mtd: nand: pxa3xx: Remove READ0 switch/case falltrough Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 13/21] mtd: nand: pxa3xx: Split prepare_command_pool() in two stages Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 14/21] mtd: nand: pxa3xx: Move the data buffer clean to prepare_start_command() Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 15/21] mtd: nand: pxa3xx: Add a read/write buffers markers Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 16/21] mtd: nand: pxa3xx: Introduce multiple page I/O support Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 17/21] mtd: nand: pxa3xx: Add multiple chunk write support Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 18/21] ARM: mvebu: Add a fixed 0Hz clock to represent NAND clock Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 19/21] ARM: mvebu: Add support for NAND controller in Armada 370/XP Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 20/21] ARM: mvebu: Enable NAND controller in Armada XP GP board Ezequiel Garcia
2013-09-19 16:01 ` [PATCH 21/21] ARM: mvebu: Enable NAND controller in Armada 370 Mirabox Ezequiel Garcia
2013-09-19 17:47 ` [PATCH 00/21] Armada 370/XP NAND support Daniel Mack
2013-09-19 18:34 ` Ezequiel Garcia
2013-09-19 21:17 ` Ezequiel Garcia
2013-09-19 21:26 ` Daniel Mack
2013-09-24 18:59 ` Ezequiel Garcia
2013-09-25 6:27 ` Brian Norris
2013-09-25 10:41 ` Ezequiel Garcia
2013-09-26 19:56 ` Brian Norris
2013-09-30 12:24 ` Ezequiel Garcia
2013-10-03 0:02 ` Brian Norris
2013-10-04 19:42 ` Ezequiel Garcia
2013-10-05 0:06 ` Brian Norris
2013-10-16 23:29 ` Ezequiel Garcia
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=20130930123756.GB2417@localhost \
--to=ezequiel.garcia@free-electrons.com \
--cc=alior@marvell.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-mtd@lists.infradead.org \
--cc=tawfik@marvell.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=w@1wt.eu \
--cc=zonque@gmail.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;
as well as URLs for NNTP newsgroup(s).