From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: Build warning in todays linus/master
Date: Mon, 21 Mar 2011 11:40:52 -0000 [thread overview]
Message-ID: <002101cbe7bc$d547c6f0$7fd754d0$@deacon@arm.com> (raw)
In-Reply-To: <20110321110105.GB2610@pulham.picochip.com>
Hi Jamie,
> I'm getting a build warning on todays master build for my V6K platform:
>
> CC arch/arm/mm/mmu.o
> arch/arm/mm/mmu.c: In function 'create_36bit_mapping':
> arch/arm/mm/mmu.c:601:10: warning: format '%08llx' expects type 'long long unsigned int', but argument
> 2 has type 'unsigned int'
> arch/arm/mm/mmu.c:614:10: warning: format '%08llx' expects type 'long long unsigned int', but argument
> 2 has type 'unsigned int'
> arch/arm/mm/mmu.c:621:10: warning: format '%08llx' expects type 'long long unsigned int', but argument
> 2 has type 'unsigned int'
> arch/arm/mm/mmu.c: In function 'create_mapping':
> arch/arm/mm/mmu.c:662:10: warning: format '%08llx' expects type 'long long unsigned int', but argument
> 2 has type 'unsigned int'
> arch/arm/mm/mmu.c:670:10: warning: format '%08llx' expects type 'long long unsigned int', but argument
> 2 has type 'unsigned int'
> arch/arm/mm/mmu.c:690:10: warning: format '%08lx' expects type 'long unsigned int', but argument 2 has
> type 'unsigned int'
>
> Which is introduced by (3a6b16 [ARM: 6675/1: use phys_addr_t instead of
> unsigned long in conversion code]), because phys_addr_t is a u32
> (!CONFIG_PHYS_ADDR_T_64BIT). I guess a cast to u64 in the printk()'s in
> arch/arm/mm/mmu.c would fix these up, is that the right approach?
It looks like one of the LPAE preparation patches has been merged
(i.e. the one which replaces unsigned long with phys_addr_t) but the
conversion specifier fixes are not yet in mainline, although they do
live in -next.
It's unfortunate that this generates warnings but I don't think you
can avoid the ordering requirements of these patches.
For now, you could try cherry-picking the rest of that patch series
from -next:
ad6b9c9 ARM: 6671/1: LPAE: use phys_addr_t instead of unsigned long in outercache functions
cae6292 ARM: 6672/1: LPAE: use phys_addr_t instead of unsigned long in mapping functions
f60892d ARM: 6673/1: LPAE: use phys_addr_t instead of unsigned long for start of membanks
29a3819 ARM: 6674/1: LPAE: use long long format when printing physical addresses and ptes
These are all in Russell's -devel branch so hopefully they'll find their
way upstream soon.
Thanks for spotting this,
Will
next prev parent reply other threads:[~2011-03-21 11:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 11:01 Build warning in todays linus/master Jamie Iles
2011-03-21 11:40 ` Will Deacon [this message]
2011-03-21 11:50 ` Jamie Iles
2011-03-21 11:58 ` Russell King - ARM Linux
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='002101cbe7bc$d547c6f0$7fd754d0$@deacon@arm.com' \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.