All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <ffainelli@freebox.fr>
To: linux-mtd@lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>,
	Matthieu CASTET <matthieu.castet@parrot.com>,
	Brian Norris <norris@broadcom.com>
Subject: Re: [PATCH 3/3] NAND: add support for reading ONFI parameters from NAND device
Date: Fri, 13 Aug 2010 11:01:31 +0200	[thread overview]
Message-ID: <201008131101.31482.ffainelli@freebox.fr> (raw)
In-Reply-To: <4C647E87.3050205@broadcom.com>

Hi,

On Friday 13 August 2010 01:06:47 Brian Norris wrote:
> Hi,
> 
> On 08/12/2010 12:47 PM, Florian Fainelli wrote:
> >> Also, previously, you said:
> >>> +   if (!is_power_of_2(val) || val == 1 || val > (1 << 4)) {
> >>> the !is_power_of_2 check does not work for ONFI version 2.1 (3), so I
> >>> would only keep the two other checks."
> >> 
> >> So why is it now:
> >>> +   if (is_power_of_2(val) || val == 1 || val > (1 << 4)) {
> >> 
> >> Is that a typo? Perhaps it's better to throw that test out altogether.
> > 
> > That was not a typo, I actually misread the ONFI specification and
> > confused bit is set, with the actual value. So this is the correct
> > check, sorry about that.

I forgot to answer that, yes, that was a typo, the original code was right 
(that is: !is_power_of_2()).

> 
> Again, I might be mistaken, but it seems that the "is_power_of_2" would
> weed out ONFI 1.0, since val would be simply 1 << 1, i.e., val == 2.
> Really, it seems that the ONFI version number may or may not be a power
> of two. If so, then we should just check individual bits as performed in
> the other tests (and perhaps include a test to be sure "val & 1 == 0")

2 is still a power of 2, even though the exponent is 1 and is_power_of_2(2) 
returns true.

From my understanding of the ONFI specification, the corresponding bit is set, 
when the ONFI version is supported. What is not clear to me and this is where 
the is_power_of_2() check will return false, is in the case we have a device 
supporting, say ONFI 2.0, we might have bits 1, 2, 3, 4 being set (30), which 
is not a power of 2. I agree with you on that. So let's just check the 
invidual bits instead starting with the higher one.

> 
> >> I "fixed" the changes I mentioned as well as a few coding style, logic
> >> cleanups, etc. (e.g. too many levels of logic, creating lines > 80
> >> chars). Here's a new patch. I didn't change over the crc function to
> >> the library function because that would require configuring the Kbuild
> >> options and setting a dependency, which I'm not familiar with. I'm
> >> certainly not an expert on most of this, so take my patch with a grain
> >> of salt!
> > 
> > It is usually as simple as doing the proper select FOO in the related
> > Kconfig.
> 
> Thanks for the tip. It worked for me.

I will respin the patch with Matthieu's comments and yours.
--
Florian

  reply	other threads:[~2010-08-13  9:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-12 12:53 [PATCH 3/3] NAND: add support for reading ONFI parameters from NAND device Florian Fainelli
2010-08-12 18:57 ` Brian Norris
2010-08-12 19:47   ` Florian Fainelli
2010-08-12 23:06     ` Brian Norris
2010-08-13  9:01       ` Florian Fainelli [this message]
2010-08-13  7:25     ` Matthieu CASTET
2010-08-13  9:00       ` Florian Fainelli

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=201008131101.31482.ffainelli@freebox.fr \
    --to=ffainelli@freebox.fr \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.com \
    --cc=norris@broadcom.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.