From: pekon <pekon@pek-sem.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: devicetree@vger.kernel.org,
Boris BREZILLON <b.brezillon.dev@gmail.com>,
kernel@stlinux.com, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mtd: nand: stm_nand_bch: add new driver
Date: Wed, 20 Aug 2014 23:32:37 +0530 [thread overview]
Message-ID: <53F4E2BD.5080205@pek-sem.com> (raw)
In-Reply-To: <20140819021248.GR18411@ld-irv-0074>
On Tuesday 19 August 2014 07:42 AM, Brian Norris wrote:
> On Wed, Aug 06, 2014 at 02:32:18AM +0530, pekon@pek-sem.com wrote:
>> On Tuesday 05 August 2014 07:53 PM, Lee Jones wrote:
>>> On Thu, 03 Jul 2014, Gupta, Pekon wrote:
>>>>>> + /* Load last page of block */
>>>>>> + offs = (loff_t)block << chip->phys_erase_shift;
>>>>>> + offs += mtd->erasesize - mtd->writesize;
>>>>>> + if (bch_read_page(nandi, offs, buf) < 0) {
>>>>
>>>> *Important*: You shouldn't call internal functions directly here..
>>>> Instead use chip->_read() OR mtd-read() that will:
>
> I'm not sure exactly what you're saying in the above line (chip->_read()
> is not a function, and and mtd-read() is syntactically incorrect),
> but...
>
> You most certainly do *not* want to call mtd->_read() directly (or any
> of the callbacks prefixed with underscores). That is one of the main
> purposes of:
>
> commit 3c3c10bba1e4ccb75b41442e45c1a072f6cded19
> Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Date: Mon Jan 30 14:58:32 2012 +0200
>
> mtd: add leading underscore to all mtd functions
>
Makes sense. Thanks for pointing this.
[...]
>
>> I think somewhere in earlier comments, Brian also supported
>> to use high-level function like mtd_read(). Also, nand_bbt.c
>> itself uses 'mtd_read(), mtd_read_oob() and mtd_write_oob()
>> at many places. So I'll let Brain decide here.
>> But having low-level function will add redundant code for
>> re-checking and aligning the addresses boundaries to block
>> and page/sector sizes.
>
> Not all checks are redundant. It's redundant to have the direct
> descendant doing the same checks that the parent does, like:
>
> mtd_read() (checks boundaries)
> |_ mtd->_read() (e.g., nand_read())
>
> So nand_read() and nand_do_read_ops() don't need the checking.
>
> But for a BBT implementation, it can help to make sure that its
> page/block/etc. arithmetic fits the right bounds when it ends up
> deciding to scan a block.
>
> Now, it still may be easy to prove that the checks are
> redundant/unnecessary for correctly-written code, but if the layering
> makes sense, then it still may be a better choice to simply use the
> high-level, self-checking API than to try to dig deeper. For instance,
> I'm pretty sure UBI does some checks to make sure it's not reading off
> the end of an MTD, but it still calls mtd_read() because it's The Right
> Thing (TM).
>
> Brian
>
Agree.. re-using mtd_*() API for non-critical paths is justified.
with regards, pekon
------------------------
Powered by BigRock.com
next prev parent reply other threads:[~2014-08-20 18:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 9:20 Lee Jones
2014-07-03 0:22 ` Brian Norris
2014-07-03 8:05 ` Boris BREZILLON
2014-07-07 23:52 ` Brian Norris
2014-07-08 7:58 ` Boris BREZILLON
2014-07-09 17:22 ` Brian Norris
2014-07-03 9:09 ` Gupta, Pekon
2014-07-08 0:16 ` Brian Norris
2014-08-05 14:23 ` Lee Jones
2014-08-05 21:02 ` pekon
2014-08-19 2:12 ` Brian Norris
2014-08-20 18:02 ` pekon [this message]
2014-07-31 16:47 ` Lee Jones
2014-07-31 17:54 ` Brian Norris
2014-08-01 9:27 ` Lee Jones
2014-08-19 2:42 ` Brian Norris
2014-08-06 10:44 ` Lee Jones
2014-08-06 10:26 ` Lee Jones
2014-07-03 0:50 ` Brian Norris
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=53F4E2BD.5080205@pek-sem.com \
--to=pekon@pek-sem.com \
--cc=b.brezillon.dev@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel.garcia@free-electrons.com \
--cc=kernel@stlinux.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
/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
Powered by JetHome