On Mon, Jul 02, 2012 at 11:07:57AM -0700, H. Peter Anvin wrote:

If there is a dependency there it should be registered, regardless if
x86 enables the clock API.

Not really, what we *should* have is the clock API available (at least
for build purposes) everywhere.  The current situation where the API is
randomly available on some architectures makes it unusuable in generic
code which is nuts and wasting time and effort, you either need ifdefs
or Kconfig hoop jumping in all the users which isn't at all sane and
means if you're doing anything generic you still need a backup plan.

What should be happening with this is the same as happens with all the
other similar APIs - the API should stub itself out where it's not
provided and the default should be that all architectures use the
generic implementation.  The overwhelming majority of clock API usage is
just enabling the clock only while the device is running to save power
when it isn't which is totally amenable to stubbing out on platforms
that don't support that level of power management.

Last I saw I saw a patch to that effect, asked what the benefit was, and
got no answer.

Are you positive about that?  I don't recall you replying any of the
times I sent out the patch and my mail archive isn't contradicting me
either.