linux核心為不同驅動的載入順序對應不同的優先順序，在
include\linux\init.h 中定義了一些巨集：
#define pure_initcall(fn) __define_initcall("0",fn,1)
#define core_initcall(fn) __define_initcall("1",fn,1)
#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
#define postcore_initcall(fn) __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
#define arch_initcall(fn) __define_initcall("3",fn,3)
#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
#define subsys_initcall(fn) __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define __initcall(fn) device_initcall(fn)
把自己的驅動的函式名用這些巨集去定義之後，
就會對應不同的載入時候的優先順序。
其中，我們寫驅動中所用到的module_init對應的是
#define module_init(x) __initcall(x);
而#define __initcall(fn) device_initcall(fn)
所以，驅動對應的載入的優先順序為6。
在上面的不同的優先順序中，
數字越小，優先順序越高。
注意：同一等級的優先順序的驅動，載入順序是鏈結過程決定的（具體是看makefile檔案中的順序），
結果是不確定的，無法去手動設定誰先誰後。
不同等級的驅動載入的順序是先優先順序高，後優先順序低
，這是確定的。
最後這些驅動載入的順序，可以檢視在根目錄下，生成的system.map。
同一級別的初始化是和編譯順序有關的，並不是和裝置列表一致。
調整驅動載入順序可通過使用不同級別的初始化，如：subsys_initcall()
module_init()
late_initcall()
linux驅動載入順序
研究mx53開發板上sgtl5000的音訊驅動時，發現有sgtl5000 i2c driver和 imx 3stack sgtl5000 audio driver兩個驅動，前面的驅動總是在前面執行，但是好像二者都是用的module init，那麼是什麼地方決定了它的執行順序呢？找到makefile內...
Linux核心驅動載入順序
問題 背光驅動初始化先於lcd驅動初始化，導致lcd驅動初始化時出現閃屏的現象。解決過程 1 mach c中platform devices列表如下 platform devices static struct platform device athena evt platform devices ...
驅動載入順序
在系統初始化的時候，決定驅動程式在什麼時候被載入的資訊儲存在登錄檔中。最早的一批驅動是由ntldr載入記憶體的 僅僅是載入 第二批是由io管理器載入記憶體的 第三批是由 scm service control manager 載入的 乙個驅動在第幾批中被載入是由 hklm system curren...