From: Alexander Hoffmann <ahoffmann@sysgo.de>
To: linux-mtd@lists.infradead.org
Cc: eauth@softsys.co.at, tharbaugh@lnxi.com
Subject: Re: Usage of MTD_UADDR_UNNECESSARY broken?
Date: Fri, 12 Nov 2004 16:15:38 +0100 [thread overview]
Message-ID: <4194D39A.9000700@sysgo.de> (raw)
In-Reply-To: <1099943453.10812.16.camel@tubarao>
Hi Thayne,
sorry for the delayed response.
Thayne Harbaugh wrote:
>On Mon, 2004-11-08 at 13:55 +0100, Alexander Hoffmann wrote:
>
>
>>Ben Dooks wrote:
>>
>>
>>
>>>On Mon, Nov 08, 2004 at 12:54:16PM +0100, Alexander Hoffmann wrote:
>>>
>>>
>>>>Hi everyone,
>>>>
>>>>can anybody please explain me the exact difference between
>>>>MTD_UADDR_DONT_CARE and MTD_UADDR_UNNECESSARY .
>>>>Because if I use MTD_UADDR_UNNECESSARY an not existing field in the
>>>>unlock_addrs array is beeing referenced
>>>>(/drivers/mtd/chips/jedec_probe.c, function cfi_jedec_setup, line 1740):
>>>>
>>>>/* Mask out address bits which are smaller than the device type */
>>>>mask = ~(p_cfi->device_type-1);
>>>>p_cfi->addr_unlock1 = unlock_addrs[uaddr].addr1 & mask;
>>>>p_cfi->addr_unlock2 = unlock_addrs[uaddr].addr2 & mask;
>>>>
>>>>
>>>hmm, thought this masking had been eliminated in later copies of
>>>the mtd code?
>>>
>>>
>
>Yes, the masking has been eliminated, but someone left the comment in
>(doh!).
>
>
>
>>Ok, you are right. But this doesn't change the fact that
>>
>>unlock_addrs[uaddr].addr1
>>
>>refers to an nonexisting field in the unlock_addrs array.
>>
>>
>
>I don't see how the code you that you described is being reached. It
>looks like the start of jedec_probe_chip() checks for UNNECESSARY and
>returns 0 (although I would expect 1) and so cfi_jedec_setup() should
>never be called with UNNECESSARY (even for subsequent chips).
>
I am working with the cdb89712 development board from cirrus. This board
has an "Intel 28F320B3B" chip
(device_id = 0x8897). Apparently, jedec_probe() finds
MTD_UADDR_0x0555_0x02AA.
for this chip, while the jedec_table[] specifies it as
MTD_UADDR_UNNECESSARY.
Since the probed unlock type is overidden by the static one, the code
_does_ reach
jedec_setup().
What I haven't really understood is this: if the code refuses chips of
type UNNECESSARY
(the return code 0 from jedec_probe() is an error), then why are so many
chips declared
as UNECESSARY in jedec_table[]?
next prev parent reply other threads:[~2004-11-12 15:15 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 [this message]
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
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=4194D39A.9000700@sysgo.de \
--to=ahoffmann@sysgo.de \
--cc=eauth@softsys.co.at \
--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.