public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Marc Oscar Singer <elf@synapse.com>
To: Chris Moore <moore@free.fr>
Cc: linux-mtd@lists.infradead.org, u.kleine-koenig@pengutronix.de
Subject: Re: [PATCH] Revised the detection for broken boot-region detection. MACRONIX parts have a custom implementation of the fixup. AMD	implemtation restore to original version that has worked fine since	2001.
Date: Wed, 17 Dec 2008 16:56:58 -0800	[thread overview]
Message-ID: <49499FDA.4010000@synapse.com> (raw)
In-Reply-To: <49497440.7050204@free.fr>

Chris Moore wrote:
> Hi Marc and the list,
>
> I am afraid to admit that I was the author of the modifications that 
> you obviously did not like :(
> Let me also admit that I am a newbie to MTD, to CFI and to NOR flash 
> devices so please correct me if I write anything stupid.
No worries.
>
> You say in the subject "AMD implemtation restore to original version 
> that has worked fine since 2001".
> You seem to imply by this that my modifications broke some previously 
> working AMD parts.
That isn't what I meant.
> I apologize if this is the case but I cannot see how.
> Which AMD part(s) did I break?
> (However I did realize after submitting my patch that it could 
> possibly break certain Macronix parts using AMD CFI PRI V1.0 that were 
> previously working more by luck than judgement.)
>
> Before submitting my patch I carefully considered whether to modify 
> the AMD fixup or to add a Macronix specific one as you did.
> It seemed to me that:-
> a) In the context of the fixup AMD referred to the "Primary Vendor 
> Command Set and Control Interface ID Code" used and not to the 
> manufacturer of the part.
> For this Macronix also use the "AMD/Fujitsu Standard Command Set".
> b) Although AIUI each manufacturer is free to choose his own Device ID 
> allocations, in practice most manufacturers use the same Device ID 
> when they clone another manufacturer's part.
> For example IIRC, AMD, Fujitsu, Spansion, EON, ESI and Macronix all use:-
> - 0xBA/0x22BA for their 29LV400 B parts
> - 0xB9/0x22B9 for their 29LV400 T parts
> I therefore concluded that it was legitimate and useful in terms of 
> avoiding duplicate code to handle Macronix in the AMD fixup routine.
> You prefer to separate the fixup routines and I accept your decision 
> (it was a close call for me).
The only risky part is that your code depended, implicitly, on the fact 
that both of the Macronix IDs had the high bit set.
IMHO, it is more clear and safer to be explicit in the way that the code 
will execute.

Your wish to avoid duplicate code seems odd in that you check for the 
macronix ID in the fixup.  Someone reading the code
is going to have to know that the amd_fixup is called for Macronix 
parts, but that would be unexpected given the way
that the
>
> However I do have one objection:-
> Your Macronix version is not equivalent to mine and I believe that my 
> version handles more parts correctly ;-)
>
> Instead of:-
>
> +                switch (cfi->id) {
> +                                /* Macronix MX29LV400CT */
> +                case 0x00ba:
> +                case 0x22ba:
> +                        extp->TopBottom = 2;                 /* 
> bottom-boot */
> +                        break;
> +                            /* Macronix MX29LV400CB */
> +                case 0x00b9:
> +                case 0x22b9:
> +                        extp->TopBottom = 3;                 /* 
> top-boot */
> +                        break;
> +                default:
> +                                /* Fall back is to assume we have
> +                                 * bottom-boot. */
> +                        extp->TopBottom = 2; /* bottom-boot */
> +                        break;
> +                }
>
>
> I would prefer:-
>
> +                switch (cfi->id) {
> +                                /* Macronix MX29LV400CB */
> +                case 0x00ba:
> +                case 0x22ba:
> +                        extp->TopBottom = 2;                 /* 
> bottom-boot */
> +                        break;
> +                default:
> +                        extp->TopBottom = (cfi->id & 0x80)
> +                                ? 3 /* top-boot */
> +                                : 2 /* bottom-boot */;
> +                        break;
> +                }
>
This is part of the unclear portion of the fixup.  Do you know of 
Macronix parts that can depend on the ID bit 7 selecting top versus
bottom boot?
>
> David Woodhouse asked me to add correct handling of a few Macronix 
> parts which are incorrectly detected by my code and I shall do this 
> once your patch goes through.
Which parts are those?  I can just resubmit with them...or you can 
submit a patch that takes care of all of this.

>
> There is one other point that I would like to make (again).
> IMHO the patch from Uwe Kleine-Koenig in this thread should be applied:-
> http://thread.gmane.org/gmane.linux.drivers.mtd/22267
> See also this thread:-
> http://thread.gmane.org/gmane.linux.drivers.mtd/22176
>
I'll check on this, but it may be a week before I can do so as I'm 
travelling soon.
> Sorry for this long ramble.
>
> Cheers,
> Chris
>
Thanks for the response.


-- 
Marc Singer
Bureau of Gizmology
elf@synapse.com
t. 206.832.3712
   800.682.0581
f. 206.381.0899

Synapse Product Development, LLC.
1511 6th Avenue, 4th floor
Seattle, WA 98101

  reply	other threads:[~2008-12-18  0:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-16 20:56 [PATCH] Revised the detection for broken boot-region detection. MACRONIX parts have a custom implementation of the fixup. AMD implemtation restore to original version that has worked fine since 2001 Marc Singer
2008-12-17 21:50 ` Chris Moore
2008-12-18  0:56   ` Marc Oscar Singer [this message]
2008-12-18  3:44     ` Chris Moore
2008-12-18 16:44       ` Marc Oscar Singer
2008-12-19  6:02         ` Chris Moore
2008-12-19  6:23 ` Chris Moore

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=49499FDA.4010000@synapse.com \
    --to=elf@synapse.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=moore@free.fr \
    --cc=u.kleine-koenig@pengutronix.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