From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] PPC: post_word_{load/store} - eliminate redundant code
Date: Wed, 21 Apr 2010 23:40:05 +0200 [thread overview]
Message-ID: <20100421214005.2100AE94F86@gemini.denx.de> (raw)
In-Reply-To: <o2o660c0f821004210729u4b63cd94n4cb40c87088f8edb@mail.gmail.com>
Dear Michael Zaidman,
In message <o2o660c0f821004210729u4b63cd94n4cb40c87088f8edb@mail.gmail.com> you wrote:
> >
> > Actually there are two parts to it:
> >
> > bootcount_store() and bootcount_load() are needed for the boot
> > counter, a generic feature; I tend to move these into
> > arch/powerpc/lib/bootcount.c; the code also needs to be rewritten to
> > use I/O accessors.
> >
> > post_word_store() and post_word_load() is architecture specific,
> > common POST code that unfortunately also gets used by the logbuffer
> > code. This should be split. Then we would have
> > arch/powerpc/lib/logbuf.c and post/arch/powerpc/post_io.c or such.
Looking at the code I wonder why we need post_word_store() and
post_word_load() functions at all. All implementations I have found
translate into a single ioread32() resp. iowrite32() call.
> Yes, I have seen them also. I actually thought to clean up them but do
> it in two phases - first make the post_word accessors to be common per
> arch and define them as weak so it will not break existing code.
> Afterwords - eliminate an existing redundant code.
>
> Thanks for the tips. Please let me know how do you want me to proceed
> with the patch?
I think we should perform this cleanup in the following steps:
1) Move bootcount_store() and bootcount_load() to architecture
specific generic locations; this includes both the PowerPC and ARM
implementations
2) Move arch/blackfin/lib/post.c to post/
3) Eliminate post_word_store() and post_word_load() and use ioread32()
resp. iowrite32() (or equivalents) directly.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I see that Microsoft's campaign to destroy all knowledge of any
operating environment but its own environment-of-the-year has
succeeded in creating a generation of users who don't understand the
concept of a shell...
-- L. Peter Deutsch in <m0x5jNX-000R2UC@lamp.aladdin.com>
next prev parent reply other threads:[~2010-04-21 21:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 16:44 [U-Boot] [RFC] PPC: post_word_{load/store} - eliminate redundant code Michael Zaidman
2010-04-20 19:55 ` Michael Zaidman
2010-04-20 21:39 ` Wolfgang Denk
2010-04-21 4:30 ` Stefan Roese
2010-04-21 7:05 ` Michael Zaidman
2010-04-21 13:24 ` Michael Zaidman
2010-04-21 13:51 ` Stefan Roese
2010-04-21 14:07 ` Michael Zaidman
2010-04-21 13:59 ` Wolfgang Denk
2010-04-21 14:29 ` Michael Zaidman
2010-04-21 21:40 ` Wolfgang Denk [this message]
2010-04-22 0:16 ` Mike Frysinger
2010-04-22 6:41 ` Michael Zaidman
2010-04-22 9:03 ` Wolfgang Denk
2010-04-22 9:27 ` Michael Zaidman
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=20100421214005.2100AE94F86@gemini.denx.de \
--to=wd@denx.de \
--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