RK3588 PCIe设备识别失败？一招避坑“非法Class”陷阱

前言：在 RK3588 平台开发过程中，你是否遇到过这样的窘境：明明 PCIe 总线上挂好了网卡模块，lspci 能识别到芯片，可驱动就是加载失败，排查半天找不到关键问题？别慌！本文将带你一步步解决这个棘手问题。

一、案例背景

使用眺望电子 RK3588核心板的PCIE20_0/1/2接口挂载裕太微yt6801芯片扩展网卡为例，看看问题到底有多棘手。

通过lspci命令查看设备状态时，能清晰看到 yt6801 芯片的存在，三个网卡设备均显示为 “Ethernet controller: Device 1f0a:6801 (rev 01)”，从表面看似乎一切正常。

可当执行insmod yt6801.ko加载驱动时，报错信息却接连弹出驱动加载直接失败，网卡根本无法使用。

明明硬件连接没问题，设备也能被识别，为什么驱动就是 “不听话”？这背后肯定藏着我们没注意到的关键细节。

二、根源分析

问题不能看表面，深入日志查原因

查看系统日志时发现，出问题的 PCIe 设备与正常设备的 class 类型截然不同。正常工作的两个 PCIe 设备（000200.0 和 000100.0），class 类型均为 0x060400；而加载驱动失败的 PCIe 设备（000400.0），class 类型却显示为 0x000000。

在SDK/kernel/include/linux/pci_ids.h文件中定义了不同class类别。其中0x000000为PCI_CLASS_NOT_DEFINED，即为未定义；而0x060400为PCI_CLASS_BRIDGE_PCI，即为PCIe桥。只有正确识别设备类型，内核才能进行后续的资源分配和驱动加载。

由于该 PCIe 设备的 class 类型非法（未定义），系统无法正确识别其功能属性，导致 Memory BAR 资源分配异常（lspci 中 BAR 资源会显示 unassigned 状态），最终造成网卡驱动加载失败。

找到根源后，解决问题就有了明确方向。

三、解决方案

想要解决这个问题，最根本的方式是联系模块供应商，让其对模块的 class 类型进行正确配置。但如果遇到无法修改硬件配置，或需要临时应急的情况，可以参考下文尝试对模块的class类型进行软件修复，具体只需如下3步：

3.1定位修改文件

打开RK3588的SDK，找到内核中的kernel/drivers/pci/quirks.c文件。该文件主要用于处理 PCI 设备的特殊配置和兼容性问题，是我们进行软件修复的关键位置。

3.2添加修复代码

在quirks.c文件中，新增以下两段代码：

1.定义 class 类型修复函数

staticvoidquirk_class_id_fixup(struct pci_dev *dev){ dev->class=0x060400;// 将class类型设置为标准PCIe桥类型}

2.注册修复逻辑

DECLARE_PCI_FIXUP_CLASS_EARLY(0x1d87,0x3588, PCI_CLASS_NOT_DEFINED,8, quirk_class_id_fixup);

这里需要注意：0x1d87是 RK3588 的 Vendor ID（厂商 ID），0x3588是对应的 Device ID（设备 ID），PCI_CLASS_NOT_DEFINED指定针对未定义 class 类型的设备进行修复，0x060400则是我们要修复到的正确 class 类型。

3.3加修复代码

代码添加完成后，重新编译内核镜像，将编译好的镜像烧录到 RK3588 核心板中，通过命令验证修复效果：

1、执行lspci命令，已正确显示为 “PCI bridge: Fuzhou Rockchip Electronics Co., Ltd Device 3588 (rev 01)”，class 类型修复成功。

2、执行insmod yt6801.ko加载驱动，此时不再出现报错信息，驱动加载成功。

3、执行ifconfig命令，能看到新增的网卡接口（如 enP4p65s0），且接口状态正常，支持 UP、BROADCAST、MULTICAST 等模式，说明网卡已能正常工作。

至此，RK3588 PCIe 非法class类型导致的网卡驱动无法加载问题，已完全解决。

四、小结

本文提供的解决方案基于特定硬件平台验证，实际应用中需根据具体设备调整VID/PID及class类型参数。如果你在 RK3588 平台或者我司核心板开发中还遇到过其他 PCIe 相关难题，请关注眺望电子公众号或在评论区留言分享，我们一起交流探讨！