From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Wed, 28 Sep 2011 12:56:47 +0200 Subject: [U-Boot] [PATCH] ARM: Convert {in, out}s[bwl] to inline functions In-Reply-To: References: <1317062895-3847-1-git-send-email-marek.vasut@gmail.com> <201109271402.52143.marek.vasut@gmail.com> Message-ID: <201109281256.47233.marek.vasut@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wednesday, September 28, 2011 12:40:01 AM Simon Glass wrote: > On Tue, Sep 27, 2011 at 5:02 AM, Marek Vasut 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