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.
Attachment:
signature.asc
Description: Digital signature
