蜗窝科技

@lsaxl：我的意思是__clk_lookup就可以找到clk，为何还使用如下两个组合 原来的clk_register + clk_register_clkdev的组合变成了clk_register + of_clk_add_provider的组合

驱动里大都使用clk_get 为什么还要单独维护，而不使用__clk_lookup这个接口呢

@linuxer，关于reserved-memory节点，查看了Documentation\devicetree\bindings\reserved-memory\reserved-memory.txt和代码后， 有几个疑问： 平台的设备树中reserved-mem下有以下三种类型的子节点 1.other_ext_mem: other_ext_region@0 { compatible = "removed-dma-pool"; no-map; reg = <0x0 0x85b00000 0x0 0xd00000>; }; 2.qseecom_mem: qseecom_region@0 { compatible = "shared-dma-pool"; reusable; alignment = <0 0x400000>; size = <0 0x1000000>; }; 3.cont_splash_mem: splash_region@0x90001000 { reg = <0x0 0x90001000 0x0 0x13ff000>; label = "cont_splash_mem"; }; 1)对于compatible = "removed-dma-pool"属性的节点，其内存不会统计在 /proc/meminfo/MemTotal中吧？ 2)对于compatible = "shared-dma-pool" 和 reusable属性的节点，按照您的文章的意思，当该节点不被驱动使用的时候，其大小会被统计在 /proc/meminfo/MemAvailable中吧？ 3）对于第三种无compatible属性的节点，其内存大小会被怎么统计？？

前辈你好，设备树解析（解析gpio）的时候，设备出现900E（砖头），这个如何定位。

@wowo：1、Physical channel page46 All Bluetooth physical channels are characterized by a PHY frequency combined with temporal parameters and restricted by spatial considerations. 我的理解就是说，它是由不同时间点所处频段组合而成的序列，是分时+跳频结合的产物。 2、LE physical channel page52 In the core system,two Bluetooth devies use a shared physical channel for communication.To achieve this,their transceivers need to be tuned to the same PHY frequency at the same time,and they need to be within a nominal range of each other. 我的理解和上面Physical channel一样。 3、LE piconet channel page52-53 Two LE physical channels are defined. The LE piconet channel is characterized by a pseudo-random sequence of PHY channels and by three additional parameters provided by the master. There are 37 LE piconet channels. 这里完全懵了，这个LE piconet channel是什么玩意？如果说是physical channel中的一类，那这个37又是什么？如果说是Rf channel，pseudo-random sequence这些又是什么？ 4、LE Piconet Physical Channel page74,Figure 4.2 Unlike BR/EDR slaves,LE slaves do not share a common physical channel with the master.Each slave communicates on a separate physical channel with the master. 按照wowo的说法，这里"a common physical channel"指的是master和slave各自的physical channel（跳频序列）共同决定而得出的一个所谓LE piconet Physical Channel ？ 第3点的一些说法，感觉推翻了我之前对piconet channel的理解。这协议说的我好醉呀，在说什么晕死。

@wowo：Hi wowo, 非常感谢回复。 是这样的，目前用户空间和kernel空间都没有timeout机制，suspend的进入完全由用户空间根据收到kernel的消息来控制。例如kernel发出一个1，用户空间判断是1才会让系统进入suspend.也就是说发送的event并没有在kernel阻止休眠或是重新进入休眠的状态,它只是发送消息，让用户空间去处理。 而我现在困惑的点是，kernel被唤醒了（例如是被USB唤醒的吧），这个时候，用户空间要根据USB的状态来做一些处理，那么USB driver就通过uevent发送了状态改变的消息，但是这个时候用户空间还没有resume完全，接收USB driver发送消息的进程还没resume,那么这个时候USB driver发送的消息是否就丢失了？用户空间也就接收不到这个消息了？ 另外我们的uevent发送机制，会将数据存放起来，直到有人去获取？

@Rafe：其实这是一个应用层面的事情，和kernel的机制已经无关了： 上报event可以唤醒系统，也可以阻止系统休眠； 如果这个event有timeout，则系统会在timeout之后重新休眠，除非其它模块重新报一个event（例如拿一把锁）； 如果这个event没有timeout，则会一直阻止系统休眠，直到有人把这个event清除（例如driver把数据放在某一个位置，并上报event，app读取数据的时候，顺便清除event。 如果理解了原理，我们有N多种方法保证你所提到的这种同步。当然，如果什么都不考虑、不去做，系统出问题是很正常的。

@Rafe：@wowo @linuxer 我想了一下，这是不是跟uevent的上报机制有关？这样问吧，当我们用uevent上报数据的时候，如果用户空间还没有resume，那么我们上报的数据这个时候去哪里了？是阻塞在那里或者说存储在了什么地方，等待用户空间来读取吗？

@dong：其实你贴出来的这几段话里面，没有提到“piconet physical channel”，而是“physical channel”，蓝牙spec的用词有的时候确实有些随意，导致读起来有些困惑。 关于“piconet channel”和“piconet physical channel”，你的理解是对的，一个是指37个RF信道（可以为所有的LE设备共享），一个是跳频序列所定义的物理信道。 不过对于物理信道来说，page74强调的是： master和slave并不共享物理信道（这个和BR/EDR不一样），也就是说，master有自己的跳频序列，每一个slave也有自己的跳频序列。只有这样做，才可以出现比较复杂的拓扑结构：“1个master对多个slave、1个slave对多个master、等等”。

@wowo @linuxer 请教一个问题： 当有中断唤醒系统的时候，我们要把该event上报到App层(通过uevent)，那么这个时候如何保证App层能收到该事件？ resume的过程，应该是kernel先resume，然后App才resume，那么上报event的时候，App岂不是存在没有ready的情况？