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

  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.