All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: pekon@pek-sem.com (pekon)
To: linux-arm-kernel@lists.infradead.org
Subject: [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 at 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

WARNING: multiple messages have this Message-ID (diff)
From: pekon <pekon-+F4LgK8oP1VBDgjK7y7TUQ@public.gmane.org>
To: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Boris BREZILLON
	<b.brezillon.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Ezequiel Garcia
	<ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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-+F4LgK8oP1VBDgjK7y7TUQ@public.gmane.org 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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>      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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-08-20 18:02 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28  9:20 [PATCH] mtd: nand: stm_nand_bch: add new driver Lee Jones
2014-05-28  9:20 ` Lee Jones
2014-05-28  9:20 ` Lee Jones
2014-07-03  0:22 ` Brian Norris
2014-07-03  0:22   ` Brian Norris
2014-07-03  0:22   ` Brian Norris
2014-07-03  8:05   ` Boris BREZILLON
2014-07-03  8:05     ` Boris BREZILLON
2014-07-03  8:05     ` Boris BREZILLON
2014-07-07 23:52     ` Brian Norris
2014-07-07 23:52       ` Brian Norris
2014-07-07 23:52       ` Brian Norris
2014-07-07 23:52       ` Brian Norris
2014-07-08  7:58       ` Boris BREZILLON
2014-07-08  7:58         ` Boris BREZILLON
2014-07-08  7:58         ` Boris BREZILLON
2014-07-09 17:22         ` Brian Norris
2014-07-09 17:22           ` Brian Norris
2014-07-09 17:22           ` Brian Norris
2014-07-09 17:22           ` Brian Norris
2014-07-03  9:09   ` Gupta, Pekon
2014-07-03  9:09     ` Gupta, Pekon
2014-07-03  9:09     ` Gupta, Pekon
2014-07-08  0:16     ` Brian Norris
2014-07-08  0:16       ` Brian Norris
2014-07-08  0:16       ` Brian Norris
2014-08-05 14:23     ` Lee Jones
2014-08-05 14:23       ` Lee Jones
2014-08-05 14:23       ` Lee Jones
2014-08-05 14:23       ` Lee Jones
2014-08-05 21:02       ` pekon
2014-08-05 21:02         ` pekon
2014-08-05 21:02         ` pekon at pek-sem.com
2014-08-19  2:12         ` Brian Norris
2014-08-19  2:12           ` Brian Norris
2014-08-19  2:12           ` Brian Norris
2014-08-19  2:12           ` Brian Norris
2014-08-20 18:02           ` pekon [this message]
2014-08-20 18:02             ` pekon
2014-08-20 18:02             ` pekon
2014-07-31 16:47   ` Lee Jones
2014-07-31 16:47     ` Lee Jones
2014-07-31 16:47     ` Lee Jones
2014-07-31 17:54     ` Brian Norris
2014-07-31 17:54       ` Brian Norris
2014-07-31 17:54       ` Brian Norris
2014-07-31 17:54       ` Brian Norris
2014-08-01  9:27       ` Lee Jones
2014-08-01  9:27         ` Lee Jones
2014-08-01  9:27         ` Lee Jones
2014-08-19  2:42         ` Brian Norris
2014-08-19  2:42           ` Brian Norris
2014-08-19  2:42           ` Brian Norris
2014-08-19  2:42           ` Brian Norris
2014-08-06 10:44     ` Lee Jones
2014-08-06 10:44       ` Lee Jones
2014-08-06 10:44       ` Lee Jones
2014-08-06 10:26   ` Lee Jones
2014-08-06 10:26     ` Lee Jones
2014-08-06 10:26     ` Lee Jones
2014-07-03  0:50 ` Brian Norris
2014-07-03  0:50   ` Brian Norris
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 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.