From: Thierry Reding <thierry.reding@gmail.com>
To: Jim Davis <jim.epost@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
linux-next <linux-next@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-pwm@vger.kernel.org
Subject: Re: randconfig build error with next-20141204, in drivers/pwm
Date: Thu, 18 Dec 2014 10:54:06 +0100 [thread overview]
Message-ID: <20141218095406.GB24383@ulmo> (raw)
In-Reply-To: <20141218094442.GA24383@ulmo>
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]
On Thu, Dec 18, 2014 at 10:44:44AM +0100, Thierry Reding wrote:
> On Thu, Dec 04, 2014 at 09:10:55AM -0700, Jim Davis wrote:
> > Building with the attached random configuration file,
> >
> > ERROR: "____ilog2_NaN" [drivers/pwm/pwm-atmel-hlcdc.ko] undefined!
>
> This took a while to figure out. The attached patch fixes this build
> failure, though the driver should probably be fixed to avoid division by
> zero, just in case. Adding Boris for visibility.
>
> Thierry
> From 7933af1d2e5f3941d934eec88f32f5547ee218c3 Mon Sep 17 00:00:00 2001
> From: Thierry Reding <thierry.reding@gmail.com>
> Date: Thu, 18 Dec 2014 10:09:42 +0100
> Subject: [PATCH] pwm: atmel-hlcdc: Depend on HAVE_CLK
>
> The include/linux/clk.h header defines dummy implementations for the
> various clk_*() functions if HAVE_CLK is not selected to improve build
> coverage in randconfig builds.
>
> The dummy implementation of clk_get_rate() returns 0, which causes the
> Atmel HLCDC PWM driver's atmel_hlcdc_pwm_config() implementation to end
> up calling:
>
> do_div(clk_period_ns, 0)
>
> On x86, do_div(n, base) will end up evaluating to this:
>
> n >>= ilog2(base)
>
> with base = 0, the implementation of ilog2() will call ____ilog2_NaN(),
> which is purposely undefined and results in a linker failure:
>
> ERROR: "____ilog2_NaN" [drivers/pwm/pwm-atmel-hlcdc.ko] undefined!
>
> The implementation of do_div() checks that base is a power of 2 before
> calling ilog2(). The compiler doesn't optimize this away, presumably
> because is_power_of_2() is an inline function and the compiler doesn't
> or can't inspect it closely enough. ilog2() being a macro it still ends
> up generating the ____ilog2_NaN() because of the constant 0.
If I turn is_power_of_2() into a macro, then this build failure also
goes away. I suppose the reason is that now the do_div() evaluates such
that the branch that would reference the undefined symbol can be
discarded.
Still I think allowing that branch to remain will cause the linker
failure on division by (constant) zero, which has some value, too.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-12-18 9:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 16:10 randconfig build error with next-20141204, in drivers/pwm Jim Davis
2014-12-18 9:44 ` Thierry Reding
2014-12-18 9:54 ` Thierry Reding [this message]
2014-12-18 19:51 ` Boris Brezillon
2014-12-19 8:50 ` Thierry Reding
2014-12-18 20:05 ` [PATCH] pwm: atmel-hlcdc: Prevent div by zero Boris Brezillon
2014-12-19 8:50 ` Thierry Reding
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=20141218095406.GB24383@ulmo \
--to=thierry.reding@gmail.com \
--cc=boris.brezillon@free-electrons.com \
--cc=jim.epost@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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.