pwm: atmel-hlcdc: Depend on HAVE_CLK
authorThierry Reding <thierry.reding@gmail.com>
Thu, 18 Dec 2014 09:09:42 +0000 (10:09 +0100)
committerThierry Reding <thierry.reding@gmail.com>
Fri, 30 Jan 2015 11:15:58 +0000 (12:15 +0100)
commitd2048c49152a414efcf8b2696896bc8803ef2f1e
tree32838cb723c326344bbdc03463ac89110af11769
parent97bf6af1f928216fd6c5a66e8a57bfa95a659672
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.

The root of the problem is that the driver really should be checking
before possibly dividing by zero. That should eventually be fixed, but
for now just assume that the clock runs at a sensible frequency when
available.

Reported-by: Jim Davis <jim.epost@gmail.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
drivers/pwm/Kconfig