On Thu, Jun 07, 2012 at 09:04:03PM -0400, Josh Boyer wrote:

> I'm not placing blame.  I'm declaring people should be cautious going
> forward.  5 arches have the clock API.  21 don't.  Whatever reasons
> there are for that, I don't care.  It should be a big warning sign.

My point here is that it's a warning sign for the API, not really for
the drivers that use it.

> It might even be beneficial to put some Kconfig dependencies on both
> CONFIG_COMMON_CLK (which is somewhat misleadingly named) and
> CONFIG_CLKDEV_LOOKUP so those are only selectable on those 5 arches.
> Something like:

>  config CLKDEV_LOOKUP
>  	bool
> +	depends on (ARM || SUPERH || MIPS || C6X || BLACKFIN)
>  	select HAVE_CLK

This is a really bad approach.  It's sending totally the wrong message
about where we want to be (we want to have the clock API available
everywhere) and more importantly it still means that drivers need to go
on carrying around ifdefery or unhelpful dependencies which is just lots
of pointless work.  A very large proportion of the drivers that use
clocks are just making sure clocks are enabled when the device is active
to integrate with system wide power optimisation and don't actually care
if there are clocks there at all, we should be making their life as easy
as possible.

A much better approach is get the stubs mentioned earlier merged
(they're already on their way) faster.  That way there are no compile
time dependencies and the problem goes away unless the driver is doing
something more active with clocks like managing the clock rate.

In the case of CLKDEV_LOOKUP the symbol should only be selected by an
architecture anyway, it's a layer on top of the architecture clock code.

> Regardless, hopefully things like this will get hit in linux-next in the
> future.  I believe the only reason that it wasn't this time is that
> none of the PPC defconfigs build in linux-next bother to build the
> driver at all.

They do generally, people do randconfig and allXconfig builds all the
time.