clk_register和 clk_register_clkdev是不是功能有些重复呢？
本文是原「蜗窝讨论区」的历史存档（2016-04-20），来自版块「Linux kernel技术问答」，共 4 帖。讨论区已停止服务，此处仅供查阅。
各位大神，在common clock framework中有两个函数：clk_register和 clk_register_clkdev，总是感觉有些功能重复，有没有人给讲一讲？
重复吗？我怎么不觉得呢？呵呵~~~我说说我的理解。
1、这两个函数各自的功能是什么呢？ 虽然名字有点像，但是这两个函数的功能并不像。对于clk_register函数而言，底层（clock provider）可以通过调用该接口注册一个clk（一个抽象的clock device）到common clock framework中。对于clk_register_clkdev而言，它实际上是注册一个struct clk_lookup到common clock framework中，就像数据结构的名字那样，这个操作主要是为了寻找clk。
2、为何需要寻找clk呢？ 我们可以从clock consumer的角度来看，在其初始化函数中，我们往往需要调用clk_get获取对应的clk，然后才可以指向clk_enable/clk_disable/clk_set_rate等操作。
3、clock consumer怎么寻找clk呢？ 在没有引入Device tree之前，clock consumer是通过clk的名字来寻找其对应的clk数据结构。我们上面说过了，clock provider驱动中会调用clk_register函数注册到common clock framework中，但是clock consumer并不知道如何定位到该clk，因此clock provider驱动中除了调用clk_register获取clk之外，随后都会立刻调用clk_register_clkdev将该clk和一个名字捆绑起来（看看struct clk_lookup的定义就明白了），并将产生的struct clk_lookup实例挂入一个全局链表中。而clk的名字就是clock consumer获取clk的唯一途径。
4、引入device tree之后，clock consumer怎么寻找clk呢？ 引入device tree之后，情况发生了一些变化。基本上每一个clock provider都会变成dts中的一个节点，也就是说，每一个clk都有一个设备树中的device node与之对应。在这种情况下，与其捆绑clk和一个“名字”，不如捆绑clk和device node（参考struct of_clk_provider），因此原来的clk_register + clk_register_clkdev的组合变成了clk_register + of_clk_add_provider的组合。
我们再看clock consumer这一侧：这时候，使用名字检索clk已经过时了，毕竟已经有了强大的device tree。我们可以通过clock consumer对应的struct device_node寻找为他提供clock signal那个clock设备对应的device node（clock属性和clock-names属性），当然，如果consumer有多个clock signal来源，那么在寻找的时候需要告知是要找哪一个时钟源（用connection ID标记）。当找了provider对应的device node之后，一切都变得简单了，从全局的clock provide链表中找到对应clk就OK了。
因此，要说功能重复，clk_register_clkdev和of_clk_add_provider重复了，在引入强大的设备树之后，clk_register_clkdev按理说应该退出历史舞台了。
5、但是最新的代码中怎么仍然有clk_register_clkdev的代码呢？很多平台上也用的很欢畅呢？ 唉，一言难尽啊......家家有本难念的经，SOC厂商往往是急功近利的，他们往往首先考虑的是完成功能，而不是考虑架构的优雅......
恩，多谢指点，明白了，今天再对着代码仔细想想。
linuxer 写道：
5、但是最新的代码中怎么仍然有clk_register_clkdev的代码呢？很多平台上也用的很欢畅呢？ 唉，一言难尽啊......家家有本难念的经，SOC厂商往往是急功近利的，他们往往首先考虑的是完成功能，而不是考虑架构的优雅......
也正因为如此，蜗窝科技上(/tag/clock)有关的文章，压根没有提clk_register_clkdev这个接口，就是不想让大家用这种旧方法。大家看代码、写代码的时候，当它不存在就是了。