From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: Convert {in, out}s[bwl] to inline functions
Date: Wed, 28 Sep 2011 12:56:47 +0200 [thread overview]
Message-ID: <201109281256.47233.marek.vasut@gmail.com> (raw)
In-Reply-To: <CAPnjgZ39_RArLzzTdF5imasDE7VWtPiMyUqmF2oL=VnqHBG4TQ@mail.gmail.com>
On Wednesday, September 28, 2011 12:40:01 AM Simon Glass wrote:
> On Tue, Sep 27, 2011 at 5:02 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > On Tuesday, September 27, 2011 01:57:52 PM Nick Thompson wrote:
> >> On 27/09/11 11:21, Marek Vasut wrote:
> >> > On Tuesday, September 27, 2011 11:31:15 AM Wolfgang Denk wrote:
> >> >> Dear Marek Vasut,
> >> >>
> >> >> In message <1317062895-3847-1-git-send-email-marek.vasut@gmail.com>
> >> >> you
> >
> > wrote:
> >> >>> The size of uboot binary grows by a few bytes, but the gain (better
> >> >>> type checking) is worth it.
> >> >>
> >> >> And what _exactly_ are "a few bytes" ?
> >> >
> >> > Nevermind, it must have been some kind of a fluctuation yesterday.
> >> > Right now, I made a new measurement and the size didn't change
> >> > with/without the patch (this is more what I'd expect to happen).
> >> >
> >> > Cheers
> >>
> >> Pure speculation on my part, but /could/ this be because ARM drivers
> >> don't tend to use these macros/functions. write[bwl] and the like are
> >> much more common. I don't know this to be a fact though.
> >
> > No, I'm dead sure I use this macro in the test.
> >
> >> Nick.
>
> Hi,
>
> Can't comment on the patch format, etc.
>
> I tested this on my Seaboard, with no code size increase, and all
> worked as expected. I can't see why it would increase code size
> either.
>
> But I have a few questions: what devices actually uses this macro?
common/cmd_ide.c for example.
> Otherwise I'm not sure if I am testing anything. Also, why not convert
> all the macros in this file? Seems like a good idea to me. Or is this
> patch just to test the waters? :-)
We should eventually get rid of all that crap altogether and unify the hardware
access. But that seems like a long-term plan :-(
Cheers
>
> Regards,
> Simon
next prev parent reply other threads:[~2011-09-28 10:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-26 18:48 [U-Boot] [PATCH] ARM: Convert {in,out}s[bwl] to inline functions Marek Vasut
2011-09-27 8:59 ` [U-Boot] [PATCH] ARM: Convert {in, out}s[bwl] " Nick Thompson
2011-09-27 9:31 ` Wolfgang Denk
2011-09-27 10:21 ` Marek Vasut
2011-09-27 11:57 ` Nick Thompson
2011-09-27 12:02 ` Marek Vasut
2011-09-27 22:40 ` Simon Glass
2011-09-28 10:56 ` Marek Vasut [this message]
2011-09-27 9:32 ` Wolfgang Denk
2011-09-27 10:08 ` Marek Vasut
2011-09-28 20:46 ` Wolfgang Denk
2011-09-28 20:58 ` Marek Vasut
2011-09-28 21:15 ` Wolfgang Denk
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=201109281256.47233.marek.vasut@gmail.com \
--to=marek.vasut@gmail.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.