1. 项目概述一次对Linux内核“硬件户口本”的深度普查在Linux内核开发与驱动的世界里platform_device是一个绕不开的核心概念。你可以把它想象成内核为那些“非标准”硬件设备建立的“户口本”。与PCI、USB这类有标准总线协议、能自动枚举的设备不同许多嵌入式SoC系统级芯片内部的硬件模块比如GPIO控制器、I2C适配器、SPI控制器、定时器、DMA引擎等它们没有“身份证”即总线ID内核无法自动发现它们。platform_device就是为这些设备手动创建的“身份档案”它告诉内核“嘿这里有一个设备它的名字叫‘xxx’资源内存、中断等是这些请为它找个合适的驱动platform_driver来管理。”那么一个正在运行的内核里到底有多少这样的“户口本”呢这就是“列出Linux内核中现存的所有platform_device”这个项目的核心。这听起来像是一个简单的查询命令但其背后涉及对Linux设备模型Device Model的深刻理解、对sysfs虚拟文件系统的熟练运用以及如何从海量信息中提取和解读关键数据。对于驱动开发者、系统移植工程师、或者任何想深入理解当前系统硬件拓扑的人来说掌握这项技能至关重要。它能帮你快速验证设备是否成功注册、排查驱动加载失败的原因、理解系统的硬件资源分配甚至是进行安全审计检查是否有未知或可疑的设备被注册。接下来我将以一个资深嵌入式Linux开发者的视角带你从原理到实操彻底搞懂如何完成这次“深度普查”并分享其中那些手册上不会写的门道和技巧。2. 核心原理与设备模型解析2.1 Platform Device 的诞生与使命要理解如何查找platform_device首先得明白它从哪来到哪去。在Linux的设备模型中一切皆文件设备信息通过sysfs通常挂载在/sys暴露给用户空间。platform_device的生命周期通常始于内核启动的早期有两种主要创建方式静态声明在板级支持包BSP或设备树Device Tree中静态定义。这是传统嵌入式开发的主流方式。开发者会在内核源码的arch/arm/mach-xxx/或通过设备树.dts文件明确描述SoC上集成了哪些设备以及它们的内存映射地址、中断号等资源。内核在启动初始化阶段会解析这些信息并生成对应的platform_device结构体将其注册到内核的platform_bus一个虚拟总线上。动态创建在驱动代码或模块中通过platform_device_register()或platform_device_alloc()等API动态创建和注册。这种方式更灵活常见于一些可插拔的模块或复杂的驱动场景。无论哪种方式一个platform_device成功注册后内核会为其在sysfs中创建对应的目录结构这是我们能从用户空间窥探其存在的根本。2.2 Sysfs通往设备信息的桥梁sysfs是内核对象kobject的文件系统表示。每个注册到内核的设备都会在/sys/devices/下有一个对应的目录。对于platform_device它们通常位于/sys/devices/platform/目录下。这个目录就是本次“普查”的核心区域。进入/sys/devices/platform/你会看到一系列以设备名命名的目录例如serial8250reg-dummyfixedregulator-xxx等。每个目录下都包含了描述这个设备的丰富属性文件例如name设备名称与驱动匹配的关键。driver一个指向当前绑定到这个设备的驱动目录的符号链接。如果为空说明没有驱动匹配。uevent用于触发热插拔事件。resource显示设备占用的资源如内存区域、中断号。设备特定的属性文件。因此我们的核心任务就是遍历/sys/devices/platform/目录并解析其中的信息。但事情没那么简单因为platform目录下可能还有子总线如platform下的spi、i2c控制器注册的设备并且有些设备可能以其他形式组织。我们需要一个更系统的方法。2.3 设备树DTS与ACPI的现代角色在现代Linux内核尤其是ARM体系架构中设备树Device Tree已经基本取代了古老的“板级文件”board file。设备树以一种硬件描述语言在.dts文件中声明系统中的所有设备及其层级关系。内核在启动时解析设备树DTB文件并根据其中的compatible属性等自动生成对应的platform_device。这意味着对于使用设备树的系统/sys/firmware/devicetree/目录下可以看到原始的设备树结构。虽然这与运行时sysfs中的platform_device不是直接一一对应一个设备树节点可能生成多个platform_device或者与其他机制结合但它是理解设备来源的重要参考。对于x86等平台ACPI高级配置与电源管理接口扮演了类似设备树的角色。理解这些背景能让我们在查看设备列表时不仅知道“有什么”还能大致推断出“它从哪来”。3. 普查工具与方法论实战知道了原理我们开始动手。有多种工具和方法可以列出platform_device它们各有优劣适用于不同场景。3.1 基础方法直接遍历Sysfs最直接的方法就是使用Shell命令查看/sys/devices/platform/目录。ls /sys/devices/platform/这条命令会列出platform总线下的直接子设备目录。但如前面所述这并不完整。一个更全面的方法是使用find命令并利用sysfs中设备目录的一个关键特征它们都包含一个名为uevent的文件。find /sys/devices -name uevent -path */platform/* | xargs grep -l DRIVERplatform | sed s|/uevent||命令拆解与原理find /sys/devices -name uevent -path */platform/*在/sys/devices目录树中查找所有路径中包含platform且名为uevent的文件。这能覆盖到嵌套在子目录下的platform设备。xargs grep -l DRIVERplatform对上一步找到的每个uevent文件用grep检查其内容是否包含DRIVERplatform。uevent文件中的DRIVER属性指明了该设备所属的总线类型platform即表示这是一个platform设备。-l参数表示只打印包含匹配项的文件名。sed s|/uevent||将匹配文件的完整路径中的/uevent部分去掉得到的就是该设备在sysfs中的目录路径。这个方法相对准确因为它通过uevent文件的内核标识来过滤能找出绝大多数“正宗”的platform设备。注意这种方法依赖于uevent文件的内容格式。虽然绝大多数情况稳定但在极早期内核或某些特殊定制内核中可能有细微差别。它是用户空间最可靠的探测方法之一。3.2 专业工具使用lsscsi的兄弟——lsplatform遗憾的是Linux标准工具集里并没有一个像lspci或lsusb那样专为platform总线设计的“lsplatform”命令。但这恰恰体现了开源社区的活力——我们可以自己创造或者使用更强大的通用工具。一个强大的替代品是udevadm它是管理udev设备管理器的命令行工具能提供极其详尽的设备信息。udevadm info --attribute-walk --path/sys/devices/platform/serial8250 | head -30这条命令可以展示指定platform设备例如serial8250的所有属性及其继承关系对于深度分析单个设备非常有用。但要列出所有我们需要结合sysfs遍历。更接近“列表”功能的是查询udev数据库udevadm info --export-db | grep -E (SUBSYSTEM|DRIVER|DEVNAME) | grep -A2 -B1 SUBSYSTEM\platform\这个命令从udev的数据库中导出所有设备信息然后过滤出子系统SUBSYSTEM为platform的记录并显示其相关的驱动和设备节点信息。输出信息非常原始需要仔细解析。3.3 内核开发者视角DebugFS与内核模块对于内核开发者或需要极致细节的情况可以求助于内核的DebugFS如果编译时启用。cat /sys/kernel/debug/platform/devices如果debugfs已挂载通常在/sys/kernel/debug且内核配置了CONFIG_DEBUG_FS和CONFIG_PLATFORM_DEVICE_DEBUG这个文件可能会提供一份内核内部视角的设备列表。但这不是标准配置在生产系统中通常不可用。另一种方法是从内核源码层面理解。所有已注册的platform_device都链接在一个全局链表上。我们可以编写一个简单的内核模块来遍历这个链表并打印信息。这无疑是功能最强大、信息最准确的方式但需要编译和插入内核模块风险较高仅适用于开发调试环境。简易内核模块示例思路#include linux/platform_device.h #include linux/device.h static int __init list_platform_init(void) { struct device *dev; dev bus_find_device_by_name(platform_bus_type, NULL, NULL); while (dev) { struct platform_device *pdev to_platform_device(dev); pr_info(Device: %s\n, pdev-name); // 可以打印更多信息如id, num_resources等 dev bus_find_device_by_name(platform_bus_type, NULL, dev-kobj.name); } return 0; }重要警告内核编程有风险。此代码仅为概念展示未处理完整的迭代和引用计数直接使用可能导致内核崩溃。在实际生产环境中绝对禁止随意插入未经验证的内核模块。3.4 自动化脚本打造你自己的lsplatform结合上述方法我们可以编写一个健壮的Shell脚本实现一个用户空间的lsplatform工具。这个脚本应该使用find和uevent方法作为核心探测机制。对每个找到的设备目录读取其name、driver符号链接目标、modalias等关键信息。以清晰的格式如表格输出提高可读性。#!/bin/bash # 简易版 lsplatform 脚本 echo Searching for platform devices under /sys/devices ... echo find /sys/devices -name uevent -path */platform/* -exec grep -q DRIVERplatform {} \; -print | while read uevent_file; do dev_dir$(dirname $uevent_file) dev_name$(cat $dev_dir/name 2/dev/null || basename $dev_dir) driver_link$(readlink $dev_dir/driver 2/dev/null) driver_name$(basename $driver_link 2/dev/null) if [ -z $driver_name ]; then driver_name(unbound) fi printf %-40s %-30s\n $dev_name $driver_name done | sort | column -t这个脚本提供了设备名和绑定驱动名的基本视图。你可以根据需要扩展它例如添加资源信息、设备树节点路径等。4. 结果解读与典型设备分析运行普查脚本或命令后你会得到一个设备列表。如何解读它们哪些是关键的下面分析一些常见的platform_device实例。4.1 系统关键基础设施设备这些设备是系统运行的基石通常由内核核心代码或早期初始化代码注册。serial8250(或ttyS*,ttyAMA*): 串口控制器。即使没有物理串口内核也常会注册一个8250兼容的串口设备用于内核消息consolettyS0。驱动名通常是serial8250。fixedregulator-*(如fixedregulator-3v3): 固定电压调节器。在设备树中定义的、电压不可变的虚拟电源设备为其他设备如SD卡、USB PHY提供电源域描述。驱动为reg-fixed-voltage。reg-dummy: 虚拟的电压调节器用于占位或满足驱动对电源的依赖要求。clk-*或clock-controller: 时钟控制器。管理SoC上各模块的时钟源。驱动名可能是clk-xxx或更具体的如imx6q-ccmi.MX6系列。pinctrl-*: 引脚控制器。管理GPIO复用功能MUX和电气属性。驱动名如pinctrl-single。watchdog: 看门狗定时器。驱动名如imx2-wdt。排查价值如果这些设备显示为(unbound)未绑定驱动往往意味着内核配置缺失未编译对应驱动或设备树描述错误可能导致对应功能如时钟、电源管理完全失效系统不稳定。4.2 外设控制器与接口设备这些设备管理着SoC与外部世界或其他芯片的通信。mmc*(如mmc0): SD/MMC卡控制器。驱动名如sdhci-esdhc-imx用于i.MX系列。*i2c*(如30a30000.i2c): I2C总线控制器。设备名通常来自设备树节点的地址或ID驱动名如imx-i2c。注意这个I2C控制器本身是一个platform_device而挂载在它上面的I2C设备如at24EEPROM是i2c_client属于I2C总线不在platform设备列表中。*spi*(如2008000.spi): SPI主控制器。情况与I2C类似。*usb*(如usb*): USB主机或设备控制器。驱动名可能为dwc2、ehci-platform、ohci-platform等。ethernet或*eth*(如2188000.ethernet): 以太网控制器。驱动名如stmmac。排查价值检查这些设备是否成功绑定驱动是验证网卡、USB、SD卡等外设是否可用的第一步。如果设备存在但无驱动需要检查内核配置和设备树节点的compatible属性是否与驱动匹配。4.3 虚拟与功能设备这些设备并非真实硬件而是为了实现某种内核功能而创建的虚拟实体。cpu*(如cpu0,cpu1): CPU热插拔和频率调节框架将每个CPU核心也抽象为一个platform_device。驱动通常是cpufreq-dt或具体的CPU频率驱动。workqueue*: 某些工作队列workqueue也会以platform设备的形式出现用于电源管理或特定初始化。*rtc*: 实时时钟。可能是独立的RTC芯片通过I2C/SPI访问也可能是SoC内部的RTC模块作为platform设备。驱动名如rtc-imxdi。4.4 解读技巧与常见模式设备命名名称通常直接来源于设备树节点的compatible属性字符串去掉厂商前缀和版本号后的一部分或者直接是节点名。像30a30000.i2c这种30a30000是寄存器基地址.i2c是节点名。驱动绑定(unbound)状态需要警惕。但并非所有(unbound)都是问题。有些设备是“供应者”如时钟、复位、调节器它们的存在是为了被其他设备消费本身可能不需要一个活跃的驱动。而功能设备如网卡、USB未绑定驱动则一定是问题。设备树关联你可以通过设备的of_node符号链接在设备目录下的of_node找到其在设备树中的节点路径或者直接去/sys/firmware/devicetree/base/下按路径查找。这对于调试设备树匹配问题至关重要。5. 高级应用场景与深度排查掌握了普查方法我们可以将其应用于更实际的工程和调试场景。5.1 场景一驱动加载失败排查假设你为一块自定义的FPGA芯片编写了platform驱动编译成模块myfpga.ko但insmod后设备没有正常工作。第一步检查设备是否注册。# 使用你的脚本或命令查看是否有你的设备名比如 myfpga-0 ./lsplatform.sh | grep myfpga如果根本找不到说明设备树或静态定义中的platform_device创建失败。需要检查设备树节点是否正确编译进了DTB。节点是否被内核正确解析检查内核启动日志中的OF:相关消息。节点是否有status okay。第二步检查驱动是否绑定。 如果设备存在但驱动显示(unbound)。检查驱动模块是否成功加载lsmod | grep myfpga。驱动的platform_driver结构体中.driver.name或.driver.of_match_table是否与设备树节点的compatible属性完全匹配包括大小写和标点。使用udevadm查看设备的modalias与驱动支持的别名对比。udevadm info -a -p /sys/devices/platform/myfpga-0 | grep -i modaliases cat /sys/devices/platform/myfpga-0/modalias第三步检查资源冲突。 如果驱动绑定了但设备无法访问进入设备目录查看resource文件。cat /sys/devices/platform/myfpga-0/resource检查显示的内存地址和中断号是否与硬件设计一致是否与其他设备冲突通过对比其他设备的resource信息。5.2 场景二系统资源审计与安全分析在安全要求高的环境中需要确保系统没有加载未知或恶意的硬件驱动。定期运行platform_device普查并与一个已知的“白名单”进行比对是一种有效的安全基线检查。你可以将正常系统的设备列表保存为基准./lsplatform.sh platform_devices_baseline.txt在需要审计时再次生成列表并进行差异比较./lsplatform.sh platform_devices_current.txt diff -u platform_devices_baseline.txt platform_devices_current.txt多出来的设备可能是新插入的硬件模块也可能是内核被植入了恶意驱动创建的虚拟设备需要重点审查。5.3 场景三功耗与电源管理分析在移动设备或物联网设备功耗优化中需要确认所有设备在空闲时是否进入了低功耗状态。许多设备的电源状态可以通过sysfs接口查看。对于platform设备可以检查其设备目录下是否有power子目录以及其中的control、runtime_status等文件。# 示例查看一个I2C控制器的电源状态 cat /sys/devices/platform/soc/30a30000.i2c/power/runtime_status如果设备不支持运行时电源管理可能就没有power目录。通过普查找出所有设备然后筛选出那些支持电源管理的进行监控是功耗分析的基础工作。6. 常见陷阱与疑难解答在实际操作中你可能会遇到一些令人困惑的情况。6.1 为什么有些设备在/sys/bus/platform/devices里却不在/sys/devices/platform/下这是sysfs组织结构的特性。/sys/bus/platform/devices是一个符号链接的集合它链接到/sys/devices下所有属于platform总线的设备无论其物理路径如何。而/sys/devices/platform/只是platform总线类型设备的一个直接父目录。如果一个platform设备在另一个总线比如一个虚拟总线的目录下创建它就不会出现在/sys/devices/platform/的子目录里但仍然会出现在/sys/bus/platform/devices的链接中。因此最可靠的遍历起点是/sys/bus/platform/devices下的所有符号链接目标或者使用基于uevent的过滤方法。6.2 设备树节点存在但sysfs里没有对应的platform_device这通常有几个原因状态禁用设备树节点中设置了status disabled;。驱动未编译内核没有编译对应compatible的驱动。即使驱动是模块如果模块未加载设备在启动时可能不会被“探测”probe但通常设备对象platform_device仍然会被创建并注册。更可能的情况是驱动被编译但匹配逻辑有问题。依赖资源缺失设备依赖的时钟、复位、调节器等资源未就绪导致设备注册失败或延迟注册。内核配置确认内核配置了CONFIG_OF设备树支持和CONFIG_PLATFORM_DEVICE。6.3 如何区分一个设备是真实的还是虚拟的没有绝对的方法但可以综合判断查看resource真实硬件设备通常有明确的内存映射地址start和end为非零值和中断号。虚拟设备的resource可能为空或地址为0。查看设备树在/sys/firmware/devicetree/base下找到对应节点看是否有reg属性。虚拟设备可能没有reg属性或者其compatible属性是simple-bus、simple-mfd这类用于创建子设备的虚拟容器。根据名称和经验像dummy、fixedregulator、clk-fixed等名称通常暗示其虚拟属性。6.4 脚本在跨不同内核版本或发行版时不稳定是的sysfs的布局和uevent的内容在不同内核版本间可能有细微变化。增强脚本健壮性的方法多重验证不仅检查DRIVERplatform还可以检查uevent中的SUBSYSTEMplatform。错误处理对cat或readlink命令添加2/dev/null避免因文件不存在导致脚本中断。使用更稳定的接口考虑使用libudev库C语言或pyudevPython来编写工具这些库提供了更稳定、高层次的API来查询设备信息它们会处理内核接口的差异。7. 从普查到洞察构建你的设备拓扑图一次简单的列表普查只是开始。真正的价值在于将信息整合形成对系统硬件拓扑的洞察。你可以将脚本升级不仅列出设备还收集其关键属性驱动状态已绑定 / 未绑定。资源信息内存区域、中断号。设备树路径通过of_node符号链接获取。电源管理状态运行时状态active, suspended。设备依赖关系通过device目录下的链接如consumer、supplier或设备树中的phandle分析设备间的依赖如哪个调节器为哪个设备供电。将这些信息以结构化的格式如JSON输出然后使用图形化工具如Graphviz生成一张可视化的系统设备关系图。这张图对于理解复杂嵌入式系统的硬件互连、排查初始化顺序问题、优化电源管理序列具有无可估量的价值。这从一个简单的“列表”命令演变成了一个强大的系统分析工具而这正是深入理解Linux设备模型所带来的能力跃迁。
