From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Kamal Dasu <kdasu.kdev@gmail.com>,
Richard Weinberger <richard@nod.at>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Broadcom Kernel Feedback List
<bcm-kernel-feedback-list@broadcom.com>,
Marek Vasut <marek.vasut@gmail.com>, Chen-Yu Tsai <wens@csie.org>,
linux-mtd <linux-mtd@lists.infradead.org>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
Han Xu <han.xu@nxp.com>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip
Date: Tue, 5 Dec 2017 11:28:15 +0100 [thread overview]
Message-ID: <20171205112815.0b59ab2d@bbrezillon> (raw)
In-Reply-To: <CAK7LNATtk9=i3HkPrW=F1YtnM1vvEM3NtMZcPNi_0C5s_X1X1A@mail.gmail.com>
On Tue, 5 Dec 2017 19:02:26 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
> 2017-12-04 18:10 GMT+09:00 Boris Brezillon
> <boris.brezillon@free-electrons.com>:
>
> >> }
> >>
> >> if (!(chip->options & NAND_OWN_BUFFERS)) {
> >> - nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
> >> - if (!nbuf)
> >> + chip->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
> >> + if (!chip->ecccalc)
> >> return -ENOMEM;
> >>
> >> - nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
> >> - if (!nbuf->ecccalc) {
> >> + chip->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
> >> + if (!chip->ecccode) {
> >> ret = -ENOMEM;
> >> goto err_free_nbuf;
> >> }
> >
> > Hm, again not directly related to this patch, but I wonder if we
> > couldn't allocate those buffers only when they are really needed.
> > For example, most NAND controllers do the ECC calculation/correct
> > in HW and simply don't need those buffers.
>
>
> The only idea I came up with is to add a new flag,
> but I am not sure if you are happy with it
> because we are removing NAND_OWN_BUFFERS.
All drivers using ->calc/code_buf are providing a ->correct() and/or
->calculate() method, so I thought we could make the allocation
dependent on the presence of one of these hooks [1].
The only exception is the denali driver, but I think we can patch it
to not use the ->code_buf buffer [2].
[1]http://code.bulix.org/2ks7yp-236649
[2]http://code.bulix.org/sxqx7o-236650
WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip
Date: Tue, 5 Dec 2017 11:28:15 +0100 [thread overview]
Message-ID: <20171205112815.0b59ab2d@bbrezillon> (raw)
In-Reply-To: <CAK7LNATtk9=i3HkPrW=F1YtnM1vvEM3NtMZcPNi_0C5s_X1X1A@mail.gmail.com>
On Tue, 5 Dec 2017 19:02:26 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
> 2017-12-04 18:10 GMT+09:00 Boris Brezillon
> <boris.brezillon@free-electrons.com>:
>
> >> }
> >>
> >> if (!(chip->options & NAND_OWN_BUFFERS)) {
> >> - nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
> >> - if (!nbuf)
> >> + chip->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
> >> + if (!chip->ecccalc)
> >> return -ENOMEM;
> >>
> >> - nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
> >> - if (!nbuf->ecccalc) {
> >> + chip->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
> >> + if (!chip->ecccode) {
> >> ret = -ENOMEM;
> >> goto err_free_nbuf;
> >> }
> >
> > Hm, again not directly related to this patch, but I wonder if we
> > couldn't allocate those buffers only when they are really needed.
> > For example, most NAND controllers do the ECC calculation/correct
> > in HW and simply don't need those buffers.
>
>
> The only idea I came up with is to add a new flag,
> but I am not sure if you are happy with it
> because we are removing NAND_OWN_BUFFERS.
All drivers using ->calc/code_buf are providing a ->correct() and/or
->calculate() method, so I thought we could make the allocation
dependent on the presence of one of these hooks [1].
The only exception is the denali driver, but I think we can patch it
to not use the ->code_buf buffer [2].
[1]http://code.bulix.org/2ks7yp-236649
[2]http://code.bulix.org/sxqx7o-236650
next prev parent reply other threads:[~2017-12-05 10:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 5:47 [PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip Masahiro Yamada
2017-12-04 5:47 ` Masahiro Yamada
2017-12-04 9:10 ` Boris Brezillon
2017-12-04 9:10 ` Boris Brezillon
2017-12-05 10:02 ` Masahiro Yamada
2017-12-05 10:02 ` Masahiro Yamada
2017-12-05 10:02 ` Masahiro Yamada
2017-12-05 10:28 ` Boris Brezillon [this message]
2017-12-05 10:28 ` Boris Brezillon
2017-12-05 10:28 ` Boris Brezillon
2017-12-05 10:41 ` Masahiro Yamada
2017-12-05 10:41 ` Masahiro Yamada
2017-12-05 10:41 ` Masahiro Yamada
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=20171205112815.0b59ab2d@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=han.xu@nxp.com \
--cc=kdasu.kdev@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=maxime.ripard@free-electrons.com \
--cc=richard@nod.at \
--cc=wens@csie.org \
--cc=yamada.masahiro@socionext.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.