public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Marek Vasut <marex@denx.de>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	linux-mtd@lists.infradead.org, Huang Shijie <shijie8@gmail.com>,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver
Date: Fri, 13 Jul 2012 12:42:08 -0500	[thread overview]
Message-ID: <50005DF0.4070508@freescale.com> (raw)
In-Reply-To: <201207131935.29169.marex@denx.de>

On 07/13/2012 12:35 PM, Marek Vasut wrote:
> Dear Brian Norris,
> 
>> On Fri, Jul 13, 2012 at 10:19 AM, Scott Wood <scottwood@freescale.com> wrote:
>>> On 07/13/2012 12:12 PM, Marek Vasut wrote:
>>>>> The NAND_CHIPOPTIONS_MSK has limited utility and is causing real bugs.
>>>>> It silently masks off at least one flag that might be set by the
>>>>> driver (NAND_NO_SUBPAGE_WRITE). This breaks the GPMI NAND driver and
>>>>> possibly others.
>>>>>
>>>>> Really, as long as driver writers exercise a small amount of care with
>>>>> NAND_* options, this mask is not necessary at all; it was only here to
>>>>> prevent certain options from accidentally being set by the driver. But
>>>>> the original thought turns out to be a bad idea occasionally. Thus,
>>>>> kill it.
>>>>>
>>>>> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
>>>>> Cc: Huang Shijie <shijie8@gmail.com>
>>>>> Cc: Marek Vasut <marex@denx.de>
>>>>
>>>> [...]
>>>>
>>>> Maybe we should simply split it into two sets of flags to make it clear
>>>> -- chip ones and controller ones ?
>>>
>>> Isn't that what we're trying to get rid of?
> 
> Sure, but aren't there controller specific properties and chip-specific 
> properties?

Yes, but there are some properties than can be specified by either one.
 If you're proposing three sets of options (chip, controller, or both),
or duplicating certain options between the sets and then checking both
everywhere, I don't see how that's an improvement.

> And than even chip-specific state?

Not sure what you mean here.

-Scott

  reply	other threads:[~2012-07-13 17:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13 16:28 [PATCH] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver Brian Norris
2012-07-13 17:12 ` Marek Vasut
2012-07-13 17:19   ` Scott Wood
2012-07-13 17:21     ` Brian Norris
2012-07-13 17:35       ` Marek Vasut
2012-07-13 17:42         ` Scott Wood [this message]
2012-07-13 17:56           ` Marek Vasut
2012-07-13 17:34     ` [PATCH] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver (REPORT SPAM) William F.
2012-07-13 17:35   ` William F.
2012-07-14  2:02 ` [PATCH] mtd: nand: allow NAND_NO_SUBPAGE_WRITE to be set from driver Huang Shijie
2012-07-17  6:20   ` Brian Norris
2012-08-17 12:32 ` Artem Bityutskiy

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=50005DF0.4070508@freescale.com \
    --to=scottwood@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    --cc=shijie8@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