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
next prev parent 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