簡單介紹一下linux驅動設計的思想發展
在夸夸其談之前，先看下i2c裝置的結構。圖摘自韋東山大大的《嵌入式linux應用開發完全手冊》
80c51裡有乙個i2c控制器，其實也就是一組暫存器，用來控制i2c的資料線和訊號線上的訊號（高低電平）。
i2c裝置就是掛載i2c匯流排的裝置，或者說負載，比如ram pcf8570,比如eeprom at24c02等
這裡可以看到i2c控制器和cpu直接相連，可以認為是cpu的裝置，eeprom是i2c的裝置，完整的i2c程式就要包括驅動i2c控制器（用來產生訊號）的驅動程式，和i2c裝置（如eeprom）的驅動程式。
3.1 裝置模型之前
下面來說驅動程式的設計思想，先從最簡單的情況說起。一些簡單的驅動程式，比如globalmem（宋寶華《linux 裝置驅動開發詳解》中的示例裝置），不像前面說的i2c結構那麼複雜，只用按部就班實現就行了。裝置資訊（全域性記憶體的位址）在驅動中直接編碼，驅動也只適配這乙個裝置，但是一旦回過頭想，隱隱覺得這樣寫是不好的：裝置資訊硬編碼，驅動程式不能通用，要是乙個驅動能給多個globalmem使用就好了。
3.2 裝置模型提出
核心在2.6提出了裝置模型（裝置-匯流排-驅動）來實現裝置驅動分層，同時形成裝置鍊錶、驅動鏈表。這顯然是使用了分層和物件導向思想。裝置是乙個物件，驅動是乙個物件，認為裝置是掛載匯流排上的，匯流排也是乙個物件。
因為不是所有的裝置都掛載匯流排上的，比如i2c的控制器、usb控制器等，它是直接整合在soc中和cpu直接相連的。為了統一裝置模型，就提出了乙個虛擬匯流排-平台匯流排（platform），相應的i2c控制器就成為platform_device。
這樣globalmem裝置就成為platform_device,globalmem驅動就成為platform_driver，兩者的匹配通過匯流排的platform_match函式來匹配——當然需要驅動和裝置的有一致的資訊（比如name）。
為了解決像i2c這樣相對複雜的裝置驅動問題，又產生了乙個i2c核心層（i2c子系統，還有其他子系統：usb子系統、網路子系統、mmc子系統等），核心層提供了i2c控制器的驅動、i2c裝置驅動的註冊銷毀、i2c的通訊方法（演算法）等功能。i2c的控制器驅動也就是i2c匯流排驅動，使用i2c核心層提供的介面來控制i2c控制器實現特殊的時序、協議、仲裁等。i2c裝置的驅動是面向i2c裝置的，根據i2c裝置的不同使用i2c匯流排驅動中提供的方法來進行i2c裝置的初始化讀寫等操作。
3.3 裝置樹
為了解決裝置資訊硬編碼的問題，linux核心3.7提出了裝置樹的概念，把裝置的硬體資訊如硬體位址、中斷位址、名字等寫在裝置樹里。這樣驅動移植時只用修改裝置樹的對應的配置檔案即可。這就解決了最開始提出的裝置資訊硬編碼的問題。個人覺得linux採用裝置樹的機制有點晚，早就該用了，畢竟把硬體資訊寫在**裡早就為人不齒了。。
實戰經驗**推薦：怎樣在linux環境下輕鬆實現基於i2c匯流排的eeprom驅動程式
linux i2c驅動
linux i2c驅動完全分析（一）
linux 驅動程式 高階字元驅動程式
ioctl方法 驅動程式的原型實現 int ioctl struct inode inode,struct file filp,unsigned int cmd,unsigned long arg ioctl 命令選擇 位段結構 number direction ioc read ioc write...
linux裝置驅動程式 字元裝置驅動程式
先留個 有一起學習驅動程式的加qq295699450 字元裝置驅動 這篇比較惱火。載入成功，但是讀不出來資料，有知道怎麼回事的，留個言，一起討論下 資料結構 struct scull mem struct scull dev dev 整個驅動程式 如下 include include include...
Linux裝置驅動程式 字元裝置驅動程式
1.檢視主裝置號，次裝置號 進入 dev目錄執行ls l，第四，五列分別為主次裝置號，10,180,1,5,這些是主裝置號，而60,63這些就是次裝置號 130 shell android dev ls l crw rw r system radio 10,60 1969 12 31 21 00 a...