All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] ppc4xx: Refactor ECC POST for AMCC Denali core
Date: Mon, 14 Jan 2008 11:56:57 -0500	[thread overview]
Message-ID: <478B9459.50103@ge.com> (raw)
In-Reply-To: <200801141740.09548.sr@denx.de>

Stefan Roese wrote:
> Hi Jerry,
> 
> On Monday 14 January 2008, Jerry Van Baren wrote:

[snip]

>> As you should have picked up by now, a sync (forcing all I/O to
>> complete) followed by eieio is silly - the eieio is superfluous.  Seeing
>> syncs/isyncs/eieios sprinkled in code is an indication that the author
>> didn't understand what was going on and, as a result, kept hitting the
>> problem with a bigger and bigger hammer until it appeared to have gone
>> away.
> 
> Now I'm glad that I'm not the author of this code. ;) But I admit that I did 
> use this "hammer" in the past.

As have we all.  The only difference is that most of us don't get 
caught.  ;-)  Open source and git: it both exposes and attributes all 
stupidity.  :-D

[snip]

> From what I see, the ECC test code uses in_be32() and friends to access the 
> memory. And these access functions have all necessary barriers already built 
> into. So most likely the additional barriers were never necessary at all. Or 
> perhaps the code was changed from using pointer access to in_be32() access.
> 
> Nevertheless the changes from Larry are looking good to me. But I also 
> forwarded them to the original author of the code for review.

Good, that is what I wanted to get across - someone familiar with the 
code and the processor reviews what, why, when, and how (Larry, you, the 
original author, the list, etc.).

I figured that there must have been barriers that didn't show up in the 
patch since it "mostly works."  I'm suspicious that there is a missing 
or misplaced barrier.  The "sync ; eieio" pixie dust that Larry removed 
makes me suspicious that something is missing going into the test.  In 
that case, the removed "sync" probably *IS* necessary, but that needs to 
be understood and commented (and possibly moved to a better location).

> Thanks again for your comments.
> 
> /me goes to mark jvb's mail as important to easier find it as reference. :)

:-) Thanks.

> Best regards,
> Stefan

Ditto,
gvb

  reply	other threads:[~2008-01-14 16:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13  7:33 [U-Boot-Users] [PATCH] ppc4xx: Refactor ECC POST for AMCC Denali core Larry Johnson
2008-01-14 14:31 ` Jerry Van Baren
2008-01-14 16:40   ` Stefan Roese
2008-01-14 16:56     ` Jerry Van Baren [this message]
2008-01-14 18:12       ` Larry Johnson
2008-01-15  9:05         ` Stefan Roese
2008-01-14 17:44   ` Larry Johnson

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=478B9459.50103@ge.com \
    --to=gerald.vanbaren@ge.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 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.