調(diào)過Linux內(nèi)核驅(qū)動的人大概都見過這么一幕設(shè)備樹里明明只是聲明了一個簡單的寄存器區(qū)域驅(qū)動里卻要ioremap、要算偏移、要加spinlock最后還會因?yàn)椴煌?qū)動改了同一片寄存器的值而互相踩踏。syscon框架就是為了收拾這個爛攤子而生的。它是一個“雜散寄存器區(qū)域的統(tǒng)一管家”在Linux內(nèi)核中占據(jù)著一個很微妙的位置——說它簡單它確實(shí)只是一個regmap的封裝說它重要從時鐘到電源管理再到硬件隨機(jī)數(shù)依賴它的驅(qū)動遍布整個內(nèi)核。這篇就圍繞syscon框架從它解決的問題出發(fā)一直講到設(shè)備樹配置、驅(qū)動調(diào)用、業(yè)務(wù)落地和踩坑經(jīng)歷。無論你是剛?cè)腴T的內(nèi)核新手還是在為某塊板子的寄存器管理發(fā)愁的老手相信都能從中拿到點(diǎn)對自己有用的東西。1. 為什么我們需要syscon框架寄存器管理到底亂在哪1.1 一次真實(shí)的寄存器沖突現(xiàn)場之前做某款多媒體SoC的適配遇到了一個很典型的場景芯片手冊里有一塊叫“SYS_CFG”的區(qū)域地址從某個基址開始總共就256個字節(jié)。里面密密麻麻分布著幾十個寄存器——bit 0控制某個外設(shè)的軟復(fù)位bit 4到bit 6是某個PLL的鎖定狀態(tài)bit 8又是另一個模塊時鐘的開關(guān)。這些寄存器之間沒有任何規(guī)律純粹是芯片設(shè)計(jì)時“順手”放在一起的。問題來了。驅(qū)動A要操作bit 0做軟復(fù)位驅(qū)動B要輪詢bit 4到bit 6判斷PLL狀態(tài)驅(qū)動C需要改bit 8的時鐘開關(guān)。如果三個驅(qū)動都拿到自己設(shè)備樹里配的reg屬性各自ioremap同一個物理地址那么會出現(xiàn)三種尷尬每個驅(qū)動都維護(hù)一份自己的ioremap映射資源浪費(fèi)還在其次關(guān)鍵是cache一致性不好處理尤其在ARM體系下設(shè)備樹里沒有標(biāo)shared-dma-coherent的區(qū)域CPU cache和device view可能不一致。驅(qū)動A讀修改寫時把驅(qū)動B剛寫好的bit覆蓋了。這種問題在調(diào)試時極其隱蔽因?yàn)閺?fù)現(xiàn)它需要精確到微秒級的時序巧合。一旦某個驅(qū)動要probe失敗或卸載它不能隨便iounmap因?yàn)閯e的驅(qū)動還在用同一塊映射。這就是典型的“系統(tǒng)控制器”場景一片寄存器不屬于任何一個獨(dú)立的功能模塊而是整個SoC的“公共設(shè)施”。syscon框架為這類場景提供了一種“共享映射統(tǒng)一訪問”的解法本質(zhì)是用regmap子系統(tǒng)來做一次共享資源管理。1.2 syscon不是一個新功能而是一種約定嚴(yán)格來說syscon并不新增任何硬件能力。它做的事情聽起來簡單但價值極大由內(nèi)核統(tǒng)一維護(hù)對某個寄存器區(qū)域的ioremap多個驅(qū)動共享同一個映射避免各自為政。通過regmap提供統(tǒng)一的讀改寫接口天然處理了cache同步和鎖問題。允許驅(qū)動之間通過regmap的lock機(jī)制避免并發(fā)訪問沖突。在設(shè)備樹層面形成一種節(jié)點(diǎn)約定大家通過syscon的phandle引用同一個控制器。打個比方?jīng)]有syscon的時候幾個驅(qū)動相當(dāng)于各自拿鑰匙開了同一間辦公室文件擺得到處都是還經(jīng)?；ハ嗄缅e。有了syscon辦公室門口多了一個管理員所有人去管理員那里登記、存取文件雖然多了一道手續(xù)但再也不會亂了。2. 設(shè)備樹中的syscon節(jié)點(diǎn)怎么聲明怎么引用2.1 從compatible開始syscon框架在設(shè)備樹中的核心就是一個節(jié)點(diǎn)它的compatible通常有兩種寫法syscon12340000 { compatible syscon, simple-mfd; reg 0x12340000 0x1000; };第一種寫法compatible里帶了simple-mfd意思是這個節(jié)點(diǎn)不僅是syscon還是一個“簡單多功能設(shè)備”——它的子節(jié)點(diǎn)通常對應(yīng)芯片手冊里的各個功能塊由simple-mfd機(jī)制自動展開probe子節(jié)點(diǎn)。第二種寫法更常見system-controller12340000 { compatible syscon; reg 0x12340000 0x1000; };這種節(jié)點(diǎn)的驅(qū)動匹配是在drivers/mfd/syscon.c里完成的。內(nèi)核會為它創(chuàng)建一個regmap并把regmap作為syscon設(shè)備的核心資源保存起來。2.2 引用方式phandle 偏移其他驅(qū)動引用syscon的方式很直接在設(shè)備樹里放一個syscon屬性some-driverabc00000 { compatible vendor,some-block; reg 0xabc00000 0x100; syscon system-controller 0x10; /* 基址偏移0x10 */ };這里system-controller是phandle指向之前定義的syscon節(jié)點(diǎn)后面的0x10表示這個驅(qū)動關(guān)心的寄存器相對于syscon基址的偏移。2.3 內(nèi)核驅(qū)動怎么拿到這個引用設(shè)備驅(qū)動側(cè)通過syscon_regmap_lookup_by_phandle來解析#include linux/mfd/syscon.h #include linux/of.h #include linux/regmap.h struct regmap *regmap; regmap syscon_regmap_lookup_by_phandle(np, syscon); if (IS_ERR(regmap)) { return PTR_ERR(regmap); }拿到regmap之后整個寄存器區(qū)域就可以像一個普通內(nèi)存塊一樣通過regmap_read/regmap_write/regmap_update_bits來訪問了。提醒syscon_regmap_lookup_by_phandle返回的regmap不需要驅(qū)動自己釋放它的生命周期由syscon設(shè)備管理。驅(qū)動remove時不要調(diào)用regmap_exit否則會double free。3. syscon的核心接口不只是regmap3.1 syscon整個家族接口syscon提供的接口并不算多但每個都很有用。我把它們梳理成三類按phandle查找、按節(jié)點(diǎn)查找、直接按地址創(chuàng)建。第一類是按phandle查找驅(qū)動代碼最常用struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np, const char *property); struct regmap *syscon_regmap_lookup_by_phandle_args(struct device_node *np, const char *property, int arg_count, unsigned int *arg);第二類是按節(jié)點(diǎn)查找struct regmap *syscon_node_to_regmap(struct device_node *np);這個接口適合已經(jīng)有struct device_node但不一定通過phandle屬性引用的場景。第三類是直接創(chuàng)建struct regmap *syscon_regmap_lookup_by_compatible(const char *s compatible);這個接口適合那種驅(qū)動不知道phandle屬性名但知道syscon節(jié)點(diǎn)的compatible字符串的場景。我最初一直想不通這個函數(shù)該怎么用后來在一個平臺驅(qū)動里看到了就是全局只有一個syscon節(jié)點(diǎn)直接按compatible找省得去改設(shè)備樹加phandle屬性。還有syscon_node_to_regmap需要特別說一句它查找的是節(jié)點(diǎn)對應(yīng)的regmap如果節(jié)點(diǎn)本身沒有建立regmap會返回錯誤。但如果節(jié)點(diǎn)加上了syscon的compatible設(shè)備驅(qū)動會為它自動創(chuàng)建regmap。3.2 regmap層的配置syscon本身是建立在一個regmap之上的。drivers/mfd/syscon.c在probe時候會根據(jù)設(shè)備樹信息配置regmapstruct regmap_config config { .reg_bits 32, .val_bits 32, .reg_stride 4, .max_register resource_size(res), };通常它會根據(jù)reg屬性的大小推斷寄存器數(shù)量但對那些“寄存器之間有空洞”的硬件可以額外在設(shè)備樹里加reg-io-width或者自定義regmap配置。我碰到過一個硬件設(shè)計(jì)寄存器偏移不是連續(xù)的中間有大量保留區(qū)域這時就得手動設(shè)置stride或者用regmap_config里更細(xì)的max_register和num_reg_defaults_raw來避免掃描到無效寄存器。4. 動手寫一個依賴syscon的驅(qū)動完整實(shí)例4.1 場景設(shè)定假設(shè)有一個硬件模塊叫“某某系統(tǒng)控制”它需要在設(shè)備初始化時完成以下操作讀取寄存器0x04判斷某個硬件加速器是否已上電。如果沒上電則在寄存器0x00寫入BIT(0)啟動上電序列。輪詢寄存器0x04直到bit3置位表示上電完成。在關(guān)機(jī)前要清除寄存器0x00的bit0并等待bit3清零。這類場景非常典型就是電源管理、外設(shè)復(fù)位和狀態(tài)輪詢的混合操作。4.2 設(shè)備樹exp_syscon: syscon12340000 { compatible syscon; reg 0x12340000 0x1000; }; hw-accelabc00000 { compatible vendor,hw-accel; reg 0xabc00000 0x200; syscon exp_syscon 0x0; };4.3 驅(qū)動代碼骨架#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/regmap.h #include linux/mfd/syscon.h #define SYSCON_PWR_CTRL 0x00 #define SYSCON_PWR_STATUS 0x04 #define PWR_ENABLE BIT(0) #define PWR_ACK BIT(3) struct hwaccel_data { struct regmap *regmap; struct device *dev; }; static int hwaccel_power_on(struct hwaccel_data *data) { unsigned int val; int ret; ret regmap_read(data-regmap, SYSCON_PWR_STATUS, val); if (ret 0) return ret; if (val PWR_ACK) return 0; /* 已上電 */ ret regmap_update_bits(data-regmap, SYSCON_PWR_CTRL, PWR_ENABLE, PWR_ENABLE); if (ret 0) return ret; /* 輪詢等待確認(rèn) */ return regmap_read_poll_timeout(data-regmap, SYSCON_PWR_STATUS, val, (val PWR_ACK), 1000, 100000); } static int hwaccel_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct device_node *np dev-of_node; struct hwaccel_data *data; struct regmap *regmap; data devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; regmap syscon_regmap_lookup_by_phandle(np, syscon); if (IS_ERR(regmap)) { dev_err(dev, failed to get syscon regmap: %ld\n, PTR_ERR(regmap)); return PTR_ERR(regmap); } >regmap_update_bits(regmap, 4, BIT(0), BIT(0));是在修改物理寄存器0x12340010。但這里有一個反直覺的點(diǎn)硬件工程師在芯片手冊里通常寫的是“寄存器0x04”意思是基址加0x04字節(jié)處的寄存器。那么對應(yīng)regmap寄存器編號就是0x04 / 4 1。我調(diào)試某IP核的時候手冊寫的寄存器偏移是0x1C結(jié)果我在regmap里直接用regmap_read(regmap, 0x1C, val)讀出來的數(shù)據(jù)永遠(yuǎn)跟預(yù)期不符最后對著代碼和手冊查了好久才發(fā)現(xiàn)偏移應(yīng)該除以4。這個坑真的很經(jīng)典。要么在代碼里保持“寄存器編號byte offset/stride”要么在驅(qū)動里顯式定義一個宏比如#define REG_OFFSET_TO_INDEX(off) ((off) / 4)把換算關(guān)系寫清楚避免事后調(diào)試時混淆。5.3 regmap的默認(rèn)配置syscon為節(jié)點(diǎn)創(chuàng)建regmap時有幾個關(guān)鍵配置項(xiàng)需要注意。reg_bits和val_bits通常都是32但有些老平臺是16位總線就要在設(shè)備樹里表示清楚或者通過驅(qū)動側(cè)的regmap_config顯式指定。max_register最好根據(jù)reg屬性的大小設(shè)定否則如果硬件只實(shí)現(xiàn)了低地址段寄存器高地址段的讀操作可能返回cease錯誤甚至觸發(fā)總線錯誤。我遇到過一個極小概率但很麻煩的問題某個syscon節(jié)點(diǎn)的物理區(qū)域只有0x400個字節(jié)但有一個驅(qū)動在寫regmap_config.max_register時漏配導(dǎo)致內(nèi)核讓后續(xù)驅(qū)動訪問到0x1000偏移處的非法地址直接Serror panic。所以使用syscon時最好在驅(qū)動里檢查一下regmap能訪問的寄存器邊界unsigned int max_reg; int ret; ret regmap_get_max_register(regmap, max_reg); if (ret 0) return ret; if (offset max_reg) { dev_err(dev, register offset out of range: 0x%x 0x%x\n, offset, max_reg); return -EINVAL; }6. syscon與老式regmap私有管理的對比到底贏在哪6.1 一個驅(qū)動私自ioremap的問題在syscon流行之前很多驅(qū)動是這么寫的static void __iomem *base; static int foo_probe(struct platform_device *pdev) { struct resource *res; res platform_get_resource(pdev, IORESOURCE_MEM, 0); base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(base)) return PTR_ERR(base); ... }然后其他驅(qū)動如果想訪問同一片區(qū)域可能要通過platform_device的私有數(shù)據(jù)或全局變量把這個base傳出去。這種方案在單驅(qū)動時很高效但對于共享寄存器區(qū)域就有致命缺陷io的訪問完全依賴誰先映射了這片內(nèi)存一旦驅(qū)動加載順序變化另一個驅(qū)動就拿不到地址。syscon的做法是把“誰持有regmap”這個信息交給內(nèi)核統(tǒng)一管理誰想用誰來查而不是誰加載早誰說了算。6.2 cache問題和自旋鎖regmap內(nèi)部對cache的處理也很講究。在大多數(shù)SoC默認(rèn)配置下內(nèi)存domain寄存器訪問需要保證cache一致性而regmap在regmap_update_bits流程里會同時考慮fast_io和cache_only等模式。雖然實(shí)際中syscon是MMIO通常不會開普通cache但regmap仍會對每次讀寫做好屏障和同步處理。相比之下如果驅(qū)動直接操作__iomem指針還要手動處理wmb()/rmb()這種內(nèi)存屏障。syscon的regmap統(tǒng)一封裝了這些細(xì)節(jié)驅(qū)動代碼可以干凈很多。6.3 模塊化和可測試性使用syscon的另一個好處是驅(qū)動代碼可以拆得更干凈底層寄存器訪問邏輯可以單獨(dú)做一個backend模塊方便在host環(huán)境做單元測試。我有個團(tuán)隊(duì)在做某電源管理子系統(tǒng)時因?yàn)殡娫葱酒募拇嫫骺刂七壿嫼蚐oC本身是解耦的就把寄存器訪問全部抽象成regmap接口然后在PC主機(jī)上用一個虛擬的regmap總線驅(qū)動來模擬硬件時序。這樣整個電源狀態(tài)機(jī)的邏輯可以在沒有硬件的情況下跑通省了大量上板時間。這完全仰仗于syscon把寄存器訪問和業(yè)務(wù)邏輯徹底解耦。7. syscon和mfd的異與同什么時候該用誰7.1 兩者解決的問題有重疊mfd是多功能設(shè)備框架通常對應(yīng)一個硬件芯片它里面有多個功能單元比如一個音頻codec里既有ADC又有DAC還有數(shù)字接口。mfd設(shè)備會創(chuàng)建多個子設(shè)備每個子設(shè)備又有一個獨(dú)立驅(qū)動。syscon看起來也可以創(chuàng)建一個多子節(jié)點(diǎn)的設(shè)備因?yàn)閟imple-mfd就是和syscon配合的。但兩者的側(cè)重點(diǎn)不同mfd側(cè)重“功能架構(gòu)”syscon側(cè)重“寄存器共享方式”。mfd是把一個物理設(shè)備拆成多個邏輯設(shè)備syscon是把一個寄存器區(qū)域共享給多個獨(dú)立設(shè)備。7.2 實(shí)際選型建議如果硬件手冊明確把某個區(qū)域定義成一個獨(dú)立的IP該IP下掛多個功能子模塊使用mfd更合理。如果多個IP之間共享一片寄存器但沒有從屬關(guān)系用syscon更合理。如果一個IP里既有多種功能又想讓外部驅(qū)動訪問該IP的某些寄存器可以考慮mfd包裝IP、內(nèi)部用syscon暴露寄存器區(qū)域兩者結(jié)合使用。我實(shí)際參與的一個項(xiàng)目就做過這種組合主控芯片里有一個混合信號處理單元它內(nèi)部有完整的mfd架構(gòu)管理ADC和比較器等子設(shè)備同時這個處理單元的寄存器區(qū)域又被另一個獨(dú)立的安全模塊引用這時在主設(shè)備里注冊一個syscon節(jié)點(diǎn)讓外部驅(qū)動通過syscon_node_to_regmap訪問就解決了跨驅(qū)動共享問題。8. 調(diào)試syscon的實(shí)用工具與心得8.1 debugfs里的regmap接口這是我最依賴的工具。內(nèi)核配置打開CONFIG_DEBUG_FS并掛載debugfs后在/sys/kernel/debug/regmap/目錄下能看到所有已注冊的regmap。每個regmap會生成幾個文件registers讀取當(dāng)前寄存器快照。access內(nèi)核會把讀寫權(quán)限信息輸出。nameregmap的名字通常和設(shè)備節(jié)點(diǎn)名對應(yīng)。如果你想快速確認(rèn)某個驅(qū)動對syscon寄存器的寫操作是否生效直接讀registers文件就能比對。但要注意debugfs里的信息只是當(dāng)前緩存狀態(tài)不代表真實(shí)硬件值如果regmap配置了cache并且發(fā)生了cache miss可能讀出來的不是最新硬件值。不過對于MMIO型的syscon一般不會開cache寫。8.2 使用tracepoint跟蹤訪問CONFIG_REGMAP_MMIO打開后內(nèi)核的tracepoint能捕捉到每次寄存器讀寫的地址和數(shù)據(jù)。調(diào)試時可以用echo 1 /sys/kernel/debug/tracing/events/regmap/regmap_reg_read/enable echo 1 /sys/kernel/debug/tracing/events/regmap/regmap_reg_write/enable cat /sys/kernel/debug/tracing/trace這樣可以清楚看到哪個驅(qū)動在什么時間讀了哪個寄存器。在排查多驅(qū)動互相踩踏的疑難雜癥時這一步的追蹤信息比邏輯分析儀還直觀。8.3 常見問題速查表問題現(xiàn)象可能原因排查方法probe返回-EPROBE_DEFERsyscon設(shè)備還沒注冊檢查設(shè)備樹syscon節(jié)點(diǎn)compatible是否匹配查看dmesg的deferred probe信息regmap_read_all返回-EIO訪問越過了regmap的max_register檢查regmap_config里max_register是否配到正確值寄存器值始終不對偏移沒有除以stride對照硬件手冊讀到的值和預(yù)期之間是否呈倍數(shù)關(guān)系兩個驅(qū)動互相覆蓋寄存器位缺少regmap鎖或者同時更新了同一寄存器確認(rèn)它們是否通過同一個regmap實(shí)例訪問檢查tracepoint確認(rèn)訪問序列syscon設(shè)備注冊失敗regmap_config里可能有無效配置內(nèi)核日志會打印syscon: invalid regmap之類信息檢查reg屬性長度8.4 一個需要特別警惕的板級問題某個平臺在低功耗休眠前要利用syscon的寄存器把整個系統(tǒng)控制單元配置到睡眠狀態(tài)。結(jié)果發(fā)現(xiàn)休眠喚醒后某些寄存器變成了隨機(jī)值。后來排查發(fā)現(xiàn)問題不在驅(qū)動而是板級設(shè)計(jì)里這片syscon區(qū)域沒有接入正確的電源域休眠時域掉電導(dǎo)致寄存器內(nèi)容丟失。驅(qū)動代碼再怎么訪問都是對的但硬件寄存器本身就沒了。這就是單片系統(tǒng)里提syscon特別容易忽視的問題syscon解決了軟件訪問問題但沒解決硬件供電問題。所以設(shè)計(jì)時要檢查這塊區(qū)域在低功耗狀態(tài)下的保持能力別把人家“系統(tǒng)控制器”當(dāng)普通內(nèi)存區(qū)域處理。9. 給驅(qū)動接入syscon時容易踩的坑與細(xì)節(jié)梳理9.1 phandle args和offset部分硬件在設(shè)計(jì)時同一片syscon區(qū)域里不同驅(qū)動關(guān)心的偏移差異很大最好的做法是讓設(shè)備樹把偏移直接傳給驅(qū)動而不是在設(shè)備樹里寫硬件寄存器絕對地址。比如power-ctrl10000000 { compatible vendor,power-ctrl; syscon exp_syscon 0x20; };驅(qū)動側(cè)用syscon_regmap_lookup_by_phandle_args來獲取struct regmap *regmap; unsigned int offset; int ret; ret syscon_regmap_lookup_by_phandle_args(np, syscon, 1, offset); if (IS_ERR(regmap)) return PTR_ERR(regmap);這樣設(shè)備樹已經(jīng)告訴了這個驅(qū)動它關(guān)心的偏移在哪驅(qū)動不需要重復(fù)定義偏移宏。與syscon_regmap_lookup_by_phandle相比這種模式更適合一個驅(qū)動內(nèi)部有多組不同寄存器的場景。9.2 不要自己持有全局regmap指針有些驅(qū)動圖省事把某個syscon的regmap指針存在全局變量里。一旦驅(qū)動被卸載重裝這個全局值就指向已釋放的內(nèi)存另一個驅(qū)動再查就只能crash。正確做法是每次需要時都通過syscon_node_to_regmap或syscon_regmap_lookup_by_phandle查詢。這可能會增加一點(diǎn)指針查找開銷但對于probe階段的調(diào)用完全可接受。如果運(yùn)行時會非常頻繁地使用可以在驅(qū)動的私有數(shù)據(jù)結(jié)構(gòu)里保存這個regmap指針而不是放進(jìn)全局。9.3 regmap的volatile范圍syscon區(qū)域里的寄存器很多是硬件狀態(tài)寄存器每次讀都會改變值。如果在regmap里配置了cache并標(biāo)記這些寄存器為non-volatile緩存會覆蓋真實(shí)狀態(tài)導(dǎo)致驅(qū)動讀到錯誤值。這也是一個很容易被忽視的點(diǎn)。特別是某平臺把syscon節(jié)點(diǎn)里的一部分寄存器當(dāng)作普通寄存器來緩存而實(shí)際它們是一讀就自清零的latched寄存器。遇到這種問題可以在regmap_config里加volatile_table來指定哪些寄存器不能被緩存。10. 使用syscon的一些進(jìn)階玩法10.1 通過syscon_reboot實(shí)現(xiàn)重啟syscon不僅能在驅(qū)動里用內(nèi)核里還有基于它實(shí)現(xiàn)的雜項(xiàng)功能。比如drivers/power/reset/syscon-reboot.c通過設(shè)備樹配置一個復(fù)位寄存器用一個節(jié)點(diǎn)配置reboot-mode { compatible syscon-reboot; offset 0x0; mask 0x08; value 0x08; };這種配置可以讓整個系統(tǒng)掛到syscon的復(fù)位寄存器上不需要為重啟專門實(shí)現(xiàn)一個平臺驅(qū)動。同樣還有syscon-poweroff。10.2 配合syscon_restart_handle或regmap的寫保護(hù)部分SoC的寄存器區(qū)域有寫保護(hù)位比如要先往某個保護(hù)寄存器寫固定值才能真正改動目標(biāo)寄存器。這種邏輯同樣可以封裝在sycon驅(qū)動里通過regmap的write回調(diào)或者reg_update_bits的往返控制在底層實(shí)現(xiàn)業(yè)務(wù)驅(qū)動無感。10.3 把syscon作為regmap cache watch點(diǎn)我們曾經(jīng)借助syscon的regmap訪問記錄來追蹤一個可疑的驅(qū)動為什么在系統(tǒng)休眠時會周期性地讀某個寄存器。通過tracepoint和debugfs的訪問統(tǒng)計(jì)找到了特定的外部訪問模式最終問題定位到bios里某種GPIO中斷誤觸發(fā)導(dǎo)致讀取行為被反復(fù)調(diào)度。syscon提供了一個統(tǒng)一觀察窗口對這種疑難雜癥的排查幫助巨大。11. 在現(xiàn)有平臺里添加syscon支持具體步驟如果要在自己的平臺里引入syscon通常就以下幾個步驟。設(shè)備樹增加syscon節(jié)點(diǎn)并確認(rèn)reg屬性和硬件手冊一致。在需要使用syscon的驅(qū)動頭文件里加入#include linux/mfd/syscon.h。驅(qū)動中通過syscon_regmap_lookup_by_phandle或syscon_node_to_regmap獲取regmap。正確換算偏移使用regmap_read/write/update_bits訪問。驗(yàn)證時用debugfs的regmap接口和tracepoint。注意probe的順序通常syscon設(shè)備會被優(yōu)先初始化。如果存在依賴順序最好讓看起來需要syscon的驅(qū)動檢查-EPROBE_DEFER并重試。這個順序看起來很簡單但實(shí)際項(xiàng)目里我見過很多次“設(shè)備樹里syscon節(jié)點(diǎn)忘了加”或者“加了節(jié)點(diǎn)但忘記把compatible設(shè)成syscon”的低級失誤。一旦syscon節(jié)點(diǎn)沒建立regmap后面所有引用的驅(qū)動全部掛在-EPROBE_DEFER上日志里一片deferred probe warning。12. 從syscon框架到“好架構(gòu)需要好抽象”12.1 一個協(xié)議和實(shí)現(xiàn)的統(tǒng)一syscon框架給我的啟發(fā)是在嵌入式/內(nèi)核開發(fā)中很多看起來“沒什么技術(shù)含量”的基礎(chǔ)組件恰恰決定了整個系統(tǒng)的穩(wěn)定性和開發(fā)效率。寄存器的訪問本身是一件小事但凡是系統(tǒng)級的共享資源它的訪問方案必須在初始設(shè)計(jì)時就統(tǒng)一。等到硬件跑起來再補(bǔ)救日志里出現(xiàn)兩三個驅(qū)動互相覆蓋bit的問題時你才會明白早用syscon的價值。12.2 面向?qū)嵺`的編程范式syscon的做法其實(shí)是一種很通用的編程范式把資質(zhì)相同的資源抽取出來做統(tǒng)一的訪問控制讓業(yè)務(wù)模塊只依賴一個抽象接口不用關(guān)注實(shí)現(xiàn)細(xì)節(jié)。這和用戶態(tài)編程里的依賴注入、服務(wù)定位有異曲同工之妙只是它發(fā)生在內(nèi)核態(tài)以設(shè)備模型和regmap為載體。每次在系統(tǒng)里碰到多個模塊搶同一個寄存器區(qū)域我的第一反應(yīng)不是去加鎖而是先想這片區(qū)域適不適合用syscon統(tǒng)一管理。只有當(dāng)需求確實(shí)非常專一時才考慮在一個驅(qū)動里直接ioremap。這個權(quán)衡標(biāo)準(zhǔn)我希望能給初入內(nèi)核的朋友一些啟發(fā)。12.3 一點(diǎn)個人心得在做過的多個項(xiàng)目里syscon幾乎成了我處理寄存器共享問題時默認(rèn)的“第一選擇”。不只是因?yàn)樗峁┝薃PI更因?yàn)樗谡麄€內(nèi)核生態(tài)里已經(jīng)形成了成熟的規(guī)范和調(diào)試工具鏈。用熟了之后你會發(fā)現(xiàn)在設(shè)備樹審查階段就能很自然地識別出哪些節(jié)點(diǎn)應(yīng)該聲明為syscon哪些驅(qū)動應(yīng)該在設(shè)備樹里引用syscon屬性。說到底內(nèi)核框架的價值不在于它多么炫技而在于它能夠讓一批驅(qū)動協(xié)同工作時不打架。syscon在這方面的設(shè)計(jì)雖然樸素但極其有效。希望這篇文章能幫你在自己的項(xiàng)目中少走一段彎路把寄存器管理變成一件“不用太操心”的事。如果在調(diào)試中遇到什么特別反直覺的問題不妨也記錄下來。內(nèi)核開發(fā)就是這樣很多知識都是在踩坑和復(fù)盤之間積淀出來的。