最近無意中有看了一遍platform機制，發現之前對它的理解有誤，以及對probe探測函式的困擾。特此梳理一下。
linux驅動模型中的三個基本概念是：驅動、裝置、匯流排。無論是裝置還是驅動在註冊是都會掛在匯流排上。匯流排負責驅動和裝置的匹配。但是有一些裝置是沒有匯流排這種概念的，比如led，於是linux引入了platform這種機制，虛擬出一條匯流排。它主要用來管理cpu的片上資源，所以platform多見於平台相關的**中，比如arch/arm/plat-s3c24xx/common-smdk.c中，platfrom_add_devices註冊了網絡卡dm9000、nand flash等裝置，在對應裝置的驅動probe函式中通過platform_get_resourceh獲得裝置資訊。
當理解了platfrom這種機制之後，有產生了新的疑惑。之前看過usb的驅動，usb裝置掛載在hub匯流排上，usb hub協議有列舉過程，從列舉過程中可以得到裝置資訊，經過的匯流排的match之後，進而去呼叫驅動的probe函式，在probe中再去註冊裝置，完成一系列初始化的操作。我的疑惑是，platfrom肯定沒有這種列舉的過程，probe怎麼被呼叫。其實如果匯流排設為自動匹配，不論裝置或驅動誰先註冊，匯流排都會去匹配另一方，匹配是根據name，最終都會呼叫驅動的probe，完成裝置初始化（建立裝置節點等）。probe完成的工作，就像不用匯流排這種機制寫的驅動程式中modul_init完成的工作內容。
linux驅動中，每一種型別的裝置都有乙個core，比如usb_core、mtd_core、led_core，core歸納了某種裝置操作的共性，當需要在它下面新增新的裝置時，其實就是按照core提供的結構向core註冊。註冊就在probe中完成。
驅動註冊的probe函式
probe的呼叫 從driver register看起 int driver register struct device driver drv klist init與init completion沒去管它，可能是2.6的這個裝置模型要做的一些工作。直覺告訴我要去bus add driver。bus...
驅動註冊的probe函式
probe的呼叫 從driver register看起 int driver register struct device driver drv klist init與init completion沒去管它，可能是2.6的這個裝置模型要做的一些工作。直覺告訴我要去bus add driver。bus...
驅動註冊的probe函式
probe的呼叫 從driver register看起 int driver register struct device driver drv klist init與init completion沒去管它，可能是2.6的這個裝置模型要做的一些工作。直覺告訴我要去bus add driver。bus...