Linux中智慧小開關rfkill

Rfkill,其中rf是Radio frequency(射頻)，主要作用是一個專門管理開關的子系統，舉例說明Android手機的通知欄可以方便地開關Airplane/BT/WiFi/Data/GPS，使用起來著實很方便。但是這是Android系統上層統一實現的，對應Linux核心以前是沒有統一的實現，隨著這種情況的增多也有專門的子系統來集中實現這個功能。這正是rfkill的工作。

上述的幾個控制例子中，或許它們每個功能被發明時都是一場革命，原理甚或設定都可能相當複雜，但是對最終的使用者來說，使用最多的也就是「開關」。

使用範例，監聽無線網絡卡硬體變化：

$ rfkill

Usage: rfkill [options] command

Options:

--version show version (0.4-1Ubuntu3 (Ubuntu))

Commands:

help

event

list [IDENTIFIER]

block IDENTIFIER

unblock IDENTIFIER

where IDENTIFIER is the index no. of an rfkill switch or one of:

<idx> all wifi wlan bluetooth uwb ultrawideband wimax wwan gps fm

$ rfkill event

1412007426.882932: idx 0 type 1 op 0 soft 0 hard 0

1412007465.911313: idx 0 type 1 op 2 soft 0 hard 1

1412007605.911553: idx 0 type 1 op 2 soft 0 hard 0

1412007705.911463: idx 0 type 1 op 2 soft 0 hard 1

1412007715.911449: idx 0 type 1 op 2 soft 0 hard 0

$

驅動中實現了複雜的特性驅動後，最好完善一個rfkill驅動就再好不過了。Rfkill從原理不過是一個新的sys檔案系統中的class。位於/sys/class/rfkill/。因為它小，所以所說的東西也不是特別多，但是因為它引起了一段經歷讓人揪心，重點寫下來。

寫在後面：

研究這個的源由是在移植一個BT驅動的時候，出現了一個怪異的現象。由於僅僅是系統版本的升級（從Android4.2升級到Android4.4）所以可以確定硬體是完好的。相應的驅動先設定後好，燒寫系統後BT測試正常。出於「不糊弄」的心態，我決定反測試一下，在核心中將BT相關選項去掉後，測試結果BT確實是不能使用了；再將驅動設定新增上卻意外發現仍然不能正常開啟。然後立刻回退版本，測試之前能正常的核心，結果還是成功開啟裝置。我就開始亂想了，BT IC被我使用軟體設定壞了？出現這種詭異的事件時，答案一般都在廁所或者去廁所的路上，我得去那裡找找，順便洗把臉，找到的概率會更高。

廁所還是給了我一些指點，先確認BT的硬體IC到底有沒有問題，將系統完整地燒回Android4.2系統，測試結果是正常的。我放心一些了，然後使用第二台進行詭異事件的重新測試，把之前的系統映象依次燒入，現象和第一台機器是一樣的。到此刻就該是逗機靈的時刻了：一旦執行了不帶BT驅動的的映象，那麼再燒寫帶BT驅動的也不能正常開啟驅動了——BT晶片沒有復位！！！這個是我的猜測，立刻完全斷電再上電，原來包含BT驅動的不能正常開啟BT的系統映象可以正常開啟了。

以之前的驗證結果為起點進行思考，我重新燒寫系統映象都是直接按「重新啟動鍵」（硬體上叫復位鍵）進行系統的重新啟動，現在發現它會引起一個問題。BT為什麼沒有在按下復位鍵的時候進行復位呢？這個同樣只是假設，萬用表伺候！先不管電路怎麼連線，直接測試BT的復位管腳，在按下復位鍵時，電壓並沒有由高電平變為低電平。這一點得到證實後，檢視原理圖得知原來BT的復位管腳並不是和總復位鍵相連，而是連線到了CPU的一個GPIO上，再然後根據這個GPIO的名字查出在Android4.2的核心驅動中是要註冊成rfkill中BT的reset管腳的。照做後一切問題得以解決。

我以前的印象中一個電路板上的所有的IC的reset管腳都是統一連線到使用者的復位開關上呢！這次認識了一直以來都僅是眼熟的rfkill。原來BT的IC一直都沒有斷電和RESET導致沒有辦法正常的開啟。

本文永久更新連結地址：http://www.linuxidc.com/Linux/2015-08/121122.htm