modprobe -D 是唯一能直接输出模块依赖路径的命令，它按 modules.dep.bin 静态解析并打印 insmod 顺序，不校验文件存在性，也不加载或卸载模块。
直接看模块依赖关系，用 modprobe -D；查模块是否能加载、为什么失败，得配合 depmod 和 dmesg 看。
怎么用 modprobe 查模块的依赖链
modprobe -D 是唯一能直接输出模块依赖路径的命令，它不加载也不卸载，只打印 insmod 顺序。比如：
modprobe -D vfat
会输出类似：
insmod /lib/modules/$(uname -r)/kernel/fs/fat/fat.ko insmod /lib/modules/$(uname -r)/kernel/fs/vfat/vfat.ko
注意三点：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
-D不检查模块是否已存在或能否加载，只按modules.dep.bin文件静态解析 - 如果模块名拼错、或对应
.ko文件缺失，-D仍可能成功输出（它不校验文件存在性） - 输出路径里的
$(uname -r)是实际内核版本，不是占位符，需确保当前/lib/modules/下有对应目录
modprobe -r 卸载时依赖处理的真实逻辑
modprobe -r 看似“卸载模块”，其实干的是三件事：检查引用计数 → 卸载目标模块 → 扫描并卸载“仅因它而被拉起”的依赖模块。但这个“自动清理”很保守：
- 只卸载那些 没有其他模块或设备在用 的依赖项，比如卸载
nvidia时，若drm_kms_helper还被intel驱动共用，就不会动它 - 如果卸载失败，错误通常是
Module <module_name> is in use</module_name>，这时要先用lsmod | grep <module_name></module_name>看谁在引用它 -
--remove-dependencies是更激进的选项，但它不会递归清理“依赖的依赖”，只清理一级直接依赖
modprobe 加载失败时，光看报错没用
常见错误如 FATAL: Module xxx not found 或 Operation not permitted，背后原因往往不在 modprobe 本身：
-
Module not found：先确认模块文件是否存在：find /lib/modules/$(uname -r) -name "xxx.ko*"；再检查depmod -a是否执行过（否则modules.dep.bin缺失，modprobe就找不到依赖） -
Operation not permitted：多数是 Secure Boot 启用导致签名验证失败，不是权限问题；可临时关 Secure Boot 测试，或用mokutil --import签名模块 - 加载后功能异常？查
dmesg | tail -20，内核日志里才有模块初始化失败、参数不识别等真实原因
哪些 modprobe 参数现在基本不用了
有些选项文档里还写着，但现代内核和发行版中已失效或被替代：
-
-l（--list）：输出空或极不完整，因为modules.builtin和modules.order改变了扫描逻辑；改用find /lib/modules/$(uname -r) -name "*.ko" | grep -i xxx -
-t（--type）：内核不再按类型组织模块目录，该参数无实际效果 -
-a（--all）：加载全部模块既慢又危险，没人真这么干；除非你是在调试 depmod 生成逻辑，否则忽略它
真正值得常驻脑中的就四个：-r、-D、-n、-v——其余都是调试边缘场景用的。
