public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Gerlando Falauto <gerlando.falauto@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] cfi: Problem with Intel Strata 28F320 flash
Date: Fri, 27 Jul 2012 16:11:14 +0200	[thread overview]
Message-ID: <5012A182.9050601@keymile.com> (raw)
In-Reply-To: <m2y64oh1kl.fsf@ohwell.denx.de>

Hi all,

On 03/09/2011 02:21 PM, Detlev Zundel wrote:
> Hi Heiko,
>
>> Maybe a way to go ... more comments?
>>
>> Below a patch, which introduces a function, which checks for
>> "protection bugfixes", and if no bugfix is found the old code is
>> executed. Just a fast RFC patch.
>>
>> bye,
>> Heiko

[...]

> Can't we introduce a field "chip_quirk" in flash_info_t, and upon flash
> enumeration check for the specific chip version and for example put a
> CFI_QUIRK_PROTECT in it for this chip.  The core code can then check for
> this flag and call functions appropriately.
>
> In other words, why not introduce a generic infrastructure for handling
> chip quirks that may need different handling for other functions also.
>
> Cheers
>    Detlev
>

Have there been (since the original posting) other instances of flash 
parts requiring quirks (like the original one introduced by Philippe De 
Muyter for the Numonyx chip)?
Is there any ongoing activity on this or any other reason to suggest it 
might be necessary to introduce such generic infrastructure (like the 
one in linux mtd, the way I understand it)?

If that's not the case, wouldn't Heicho's original patch in this thread
(http://patchwork.ozlabs.org/patch/86063/) just be good enough for the 
purpose?

Thanks,
Gerlando

  reply	other threads:[~2012-07-27 14:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-08 13:08 [U-Boot] cfi: Problem with Intel Strata 28F320 flash Heiko Schocher
2011-03-08 14:26 ` Philippe De Muyter
2011-03-09  6:41   ` Heiko Schocher
2011-03-09 13:21     ` Detlev Zundel
2012-07-27 14:11       ` Gerlando Falauto [this message]
2012-07-30 11:07         ` Heiko Schocher
2012-07-30 11:11           ` Stefan Roese
2012-08-03  8:01           ` Stefan Roese

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=5012A182.9050601@keymile.com \
    --to=gerlando.falauto@keymile.com \
    --cc=u-boot@lists.denx.de \
    /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