[PATCH] mmc: card: modify mmc_getgeo function
Russell King - ARM Linux
linux at arm.linux.org.uk
Mon Sep 26 09:09:08 EDT 2011
On Mon, Sep 26, 2011 at 08:41:13AM -0400, Chris Ball wrote:
> Hi,
>
> On Mon, Sep 26 2011, Uwe Kleine-König wrote:
> >> Thanks, pushed to mmc-next for 3.2 with a reworded commit message:
> > This (i.e. ee9e0e0 (mmc: card: Remove duplicated constants) in next)
> > makes gcc emit a reference to __aeabi_uldivmod in one of my nightly
> > builds which isn't defined.
> >
> > The final linking stage fails with:
> >
> > LD .tmp_vmlinux1
> > drivers/built-in.o: In function `mmc_blk_getgeo':
> > clkdev.c:(.text+0xd1528): undefined reference to `__aeabi_uldivmod'
> > make[2]: *** [.tmp_vmlinux1] Error 1
> > make[1]: *** [sub-make] Error 2
> > make: *** [all] Error 2
>
> Interesting, thanks. It builds fine here on my (gcc-4.6) ARM toolchains.
> Looking online, I think you're hitting an old gcc-4.3 bug?
Check your setting of CONFIG_LBDAF - the return type from get_capacity
depends on this (which may be either unsigned long or u64).
Now, the thing about a constant division by (16*4) is that its relatively
easy for gcc to spot that this is the same as a shift - and use a shift
instead of a divide for both the unsigned long and u64 cases.
However, the change may result in gcc no longer realizing that it's a
constant division by a power-of-2, and that optimization can be applied.
If you want to eliminate these constants, I'd suggest two definitions
MMC_GEO_SECTORS
MMC_GEO_HEADS
and just subsituting the '4' and '16' in the function with the appropriate
symbolic constants. That'd avoid causing this regression.
More information about the linux-arm-kernel
mailing list