From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] PPC: post_word_{load/store} - eliminate redundant code
Date: Wed, 21 Apr 2010 20:16:55 -0400 [thread overview]
Message-ID: <201004212016.56766.vapier@gentoo.org> (raw)
In-Reply-To: <20100421214005.2100AE94F86@gemini.denx.de>
On Wednesday 21 April 2010 17:40:05 Wolfgang Denk wrote:
> Michael Zaidman 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.
i'd love to see post/ be de-powerpc-ified and unify Blackfin stuff in there.
it's been an item long standing on our side, but there's always been more
pressing issues.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100421/8ff7a06c/attachment.pgp
next prev parent reply other threads:[~2010-04-22 0:16 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
2010-04-22 0:16 ` Mike Frysinger [this message]
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=201004212016.56766.vapier@gentoo.org \
--to=vapier@gentoo.org \
--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