From: Erwin Authried <eauth@softsys.co.at>
To: tharbaugh@lnxi.com
Cc: linux-mtd@lists.infradead.org, Alexander Hoffmann <ahoffmann@sysgo.de>
Subject: Re: Usage of MTD_UADDR_UNNECESSARY broken?
Date: Thu, 18 Nov 2004 16:26:47 +0100 [thread overview]
Message-ID: <1100791607.623.10.camel@justakiss> (raw)
In-Reply-To: <1100789053.3171.96.camel@tubarao>
Am Don, den 18.11.2004 schrieb Thayne Harbaugh um 15:44:
> On Thu, 2004-11-18 at 11:50 +0100, Alexander Hoffmann wrote:
>
> > Then I guess that there is really the bug I described in my first mail.
> > I would recommend a check for MTD_UADDR_UNNECESSARY in the
> > cfi_jedec_setup(), before
> > the unlock_addrs[] array is referenced:
> >
> > if ( uaddr != MTD_UADDR_UNNECESSARY ) {
> > p_cfi->addr_unlock1 = unlock_addrs[uaddr].addr1 & mask;
> > p_cfi->addr_unlock2 = unlock_addrs[uaddr].addr2 & mask;
> > }
> > return 1;
>
> Apparently the "& mask" is not done anymore - you must be using an older
> version of jedec_probe.c.
>
> It looks like your suggestion might be appropriate after the window
> check in jedec_setup() and before the finfo_uaddr() lookup.
>
> I'm still trying to sort the test at the top of jedec_probe_chip():
>
> retry:
> if (!cfi->numchips) {
> uaddr_idx++;
>
> if (MTD_UADDR_UNNECESSARY == uaddr_idx)
> return 0;
>
> cfi->addr_unlock1 = unlock_addrs[uaddr_idx].addr1;
> cfi->addr_unlock2 = unlock_addrs[uaddr_idx].addr2;
> }
>
>
> I'm thinking that the MTD_UADDR_UNNECESSARY test (which checks for the
> end-of-loop condition) should be *prior* to the uaddr_idx++. The way it
> is, chips that are MTD_UADDR_UNNECESSARY will *never* be tested and will
> *always* fail.
I believe that your conclusion is wrong. jedec_probe doesn't know
a-priori which chip is there, thus it can't omit the test. A test for a
chip with MTD_UADDR_UNNECESSARY will match at the first tested unlock
address, because a chip with MTD_UADDR_UNNECESSARY doesn't care about
the unlock sequence at all.
Regards,
Erwin
next prev parent reply other threads:[~2004-11-18 15:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-08 11:54 Usage of MTD_UADDR_UNNECESSARY broken? Alexander Hoffmann
2004-11-08 12:06 ` Ben Dooks
2004-11-08 12:55 ` Alexander Hoffmann
2004-11-08 19:50 ` Thayne Harbaugh
2004-11-12 15:15 ` Alexander Hoffmann
2004-11-12 15:55 ` Erwin Authried
2004-11-12 16:17 ` Alexander Hoffmann
2004-11-12 16:41 ` Erwin Authried
2004-11-18 10:50 ` Alexander Hoffmann
2004-11-18 14:44 ` Thayne Harbaugh
2004-11-18 15:26 ` Erwin Authried [this message]
2004-11-19 12:50 ` Marius Groeger
2004-11-19 13:13 ` Marius Groeger
2004-11-19 20:35 ` Thayne Harbaugh
2004-11-08 18:30 ` Thayne Harbaugh
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=1100791607.623.10.camel@justakiss \
--to=eauth@softsys.co.at \
--cc=ahoffmann@sysgo.de \
--cc=linux-mtd@lists.infradead.org \
--cc=tharbaugh@lnxi.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.