企业官网建设流程全解析

1. 项目概述：为什么以太网驱动开发是嵌入式工程师绕不开的硬核关卡

在嵌入式系统里，"能跑通"和"能用好"之间隔着一整条产线。我见过太多项目，Linux内核成功启动了，串口打印也正常，但一到网络功能就卡死——ping不通、DHCP拿不到IP、TCP连接超时，甚至网卡根本不出现在ifconfig -a列表里。这时候翻日志，dmesg | grep eth满屏都是failed to initialize,probe failed,no PHY found……不是硬件虚焊，就是驱动没对上时序，更常见的是PHY地址配错、MDIO总线初始化失败、或者MAC与PHY之间的电气特性没调平。这期讲的Ethernet驱动开发，不是教你怎么抄个现成的drivers/net/ethernet/stmmac/stmmac_main.c编译过去就完事，而是带你拆开看：从物理层的RJ45接口阻抗匹配，到数据链路层的DMA描述符环管理，再到网络栈入口的SKB（socket buffer）投递机制，每一层都藏着能让你调试三天三夜的坑。核心关键词就三个：嵌入式、驱动开发、Ethernet——它们组合起来，意味着你得同时懂硬件电路、芯片手册、Linux内核子系统、以及真实产线里那些不会写进Datasheet的“潜规则”。比如，同一颗RTL8211F PHY，在A板上用0x00地址能通信，在B板上必须改成0x01，原因可能是PCB走线长度差了8cm导致MDIO时序偏移；再比如，Zynq平台用AXI Ethernet Lite，但实际项目中发现它不支持巨型帧（Jumbo Frame），而客户要求传输16KB的工业图像包，这就逼着你去改MAC的MTU配置和DMA缓冲区大小。这些都不是书本知识，是焊台边、示波器前、逻辑分析仪上熬出来的经验。适合谁？正在做工业网关、车载终端、电力DTU、医疗设备联网模块的嵌入式工程师；准备跳槽嵌入式Linux驱动岗的中级开发者；还有那些被“以太网配置”四个字困在面试最后一关的应届生——本期内容，就是帮你把“配置”二字背后那几十页寄存器手册、上百行初始化代码、以及三次握手失败时抓包看到的ARP请求重传次数，真正变成你脑子里的肌肉记忆。

2. 整体设计思路：从硬件抽象到协议栈对接的四层穿透模型

2.1 硬件层：为什么PHY地址、时钟源、复位时序比代码还重要

嵌入式以太网驱动的第一道门槛，根本不在代码里，而在原理图上。我经手过7个不同主控平台（STM32H7、i.MX6ULL、RK3399、Zynq-7000、ESP32-C3、NXP S32K144、全志H616）的以太网模块，发现一个铁律：驱动代码可以抄，但硬件适配必须重来。举个最典型的例子：PHY芯片的地址配置。RTL8211E/F默认地址是0x00，但很多国产PHY（如KSZ8081）通过ADDR[1:0]引脚接地或接VCC来设定地址，而这个引脚在PCB上可能被设计成可跳线——结果A版本板子跳0x00，B版本为了兼容旧固件跳成了0x01。如果你直接用内核默认的phy_id = 0x00去probe，B板就会报phy_connect() failed。解决方法不是改代码，而是先用万用表量ADDR引脚电平，再查PHY datasheet确认对应地址，最后在设备树里显式指定：

&fec { phy-mode = "rgmii-id"; phy-handle = <&phy0>; phy0: ethernet-phy@1 { reg = <0x1>; // 关键！这里必须和硬件一致 ti,rx-internal-delay = <0x8>; ti,tx-internal-delay = <0xa>; }; };

再比如时钟源。i.MX6ULL的ENET_REF_CLK必须由外部晶振提供（25MHz），但有些方案为了省料，用内部PLL分频生成，结果在高温环境下时钟抖动超标，PHY无法完成自协商（Auto-negotiation）。实测数据：当REF_CLK Jitter > 1.5ps RMS时，1000BASE-T协商成功率从99.9%暴跌至62%。所以硬件评审阶段，必须拿着示波器测REF_CLK眼图，而不是只看原理图标注“25MHz”。复位时序更是隐形杀手——PHY芯片要求上电后至少等待10ms才能拉高复位信号，且复位脉冲宽度需>100ns。但很多设计把PHY_RST和MCU_RST共用一个RC电路，导致MCU刚起来就急着初始化MAC，而PHY还在“睡懒觉”。我的做法是：在设备树里加reset-gpios，并在驱动probe函数开头强制msleep(20)，宁可慢一点，也不能让PHY处于未就绪状态。

2.2 驱动层：MAC控制器与PHY的协同初始化流程

Linux内核的网络驱动采用“MAC+PHY”分离架构，这是为了解耦硬件差异。但分离不等于独立——MAC驱动（如stmmac、fec、dwmac）负责收发帧、DMA管理、中断处理；PHY驱动（如realtek、marvell、micrel）负责链路状态检测、速率协商、寄存器读写。二者通过MDIO总线通信，而MDIO的稳定性直接决定整个以太网能否启动。我画过一张初始化时序图（文字版）：

1. 平台初始化：内核解析设备树，调用platform_driver_register()注册MAC驱动；
2. MAC probe：分配内存、映射寄存器、申请中断、初始化DMA环（注意：描述符内存必须dma_alloc_coherent()分配，否则Cache一致性出问题）；
3. MDIO bus probe：扫描MDIO总线上的PHY地址（0x0~0x1f），对每个地址发送PHY_ID_REG读取指令；
4. PHY识别：收到有效ID（如RTL8211F返回0x001cc915）则创建PHY device；
5. PHY connect：调用phy_connect()绑定MAC与PHY，此时PHY驱动开始工作；
6. 链路启动：PHY执行自协商，MAC监听PHY_INTERRUPT，收到LINK_UP后启用接收DMA通道。

这个流程里，第3步最容易出问题。常见故障：mdio_read()返回0xffff，说明MDIO总线没响应。排查顺序必须是：

• 检查MDIO时钟（通常为2.5MHz，用示波器测MDC引脚）；
• 测MDIO数据线（MDIO）上拉电阻是否为2.2kΩ（标准值）；
• 查MAC寄存器GMIIDR（GMII MDIO Data Register）是否可读写；
• 最后才是PHY供电和复位。

我曾遇到一个案例：MDIO总线始终无响应，查遍硬件无果，最后发现是设备树里phy-mode = "rgmii"写成了"rgmii-id"，导致内核加载了错误的PHY驱动，根本没走到MDIO扫描环节。这种低级错误，恰恰说明理解整个初始化链条比写代码更重要。

2.3 协议栈层：SKB如何从DMA缓冲区抵达应用层

当PHY链路UP后，数据包怎么从网线进入你的recvfrom()？这中间隔着三层关键转换：

• DMA层：MAC控制器将接收到的以太网帧（含FCS校验）DMA搬运到预分配的RX描述符缓冲区；
• 驱动层：stmmac_rx()函数遍历RX描述符环，对每个有效帧：
  • 检查OWN_BIT（所有权位，0=CPU可读，1=DMA可写）；
  • 调用netdev_alloc_skb_ip_align()分配SKB；
  • skb_copy_to_linear_data()将帧数据拷贝进SKB的data区域；
  • skb_put()设置len，skb->protocol = eth_type_trans()解析以太网类型（IPv4/ARP等）；
  • netif_receive_skb()将SKB提交给协议栈；
• 协议栈层：__netif_receive_skb_core()根据skb->protocol分发到ip_rcv()或arp_rcv()，最终进入socket接收队列。

这里有个性能陷阱：SKB分配是高频操作，必须避免内存碎片。实测发现，如果RX描述符缓冲区大小设为1536字节（标准MTU+14字节以太网头+4字节FCS+2字节对齐），而SKB分配时alloc_skb()请求1536字节，内核会频繁触发kmalloc()，导致内存碎片化。解决方案是：在驱动probe时预分配一批固定大小的SKB池（kmem_cache_create()），RX处理时从池中获取，释放时归还——这样能把中断上下文中的内存分配延迟从微秒级降到纳秒级。我在一个工业相机采集项目中，用此法将100Mbps持续流量下的丢包率从0.8%降至0.002%。

2.4 应用层对接：为什么ifconfig up只是开始，不是结束

很多工程师以为ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up执行成功就万事大吉，其实这只是网络栈的“门开了”，真正的考验在门后：

• ARP表维护：第一次ping网关时，内核会发ARP请求，若PHY链路不稳定，ARP超时重传3次后才放弃，表现为“ping通但延迟极高”；
• TCP窗口管理：嵌入式设备内存小，/proc/sys/net/ipv4/tcp_rmem默认值（4096 131072 6291456）会导致大量SKB堆积，OOM Killer可能干掉你的应用进程；
• 时间戳精度：NTP同步依赖精确时钟，而很多PHY的PTP（Precision Time Protocol）功能需要MAC驱动显式使能，否则chrony同步误差达±50ms；
• QoS策略：工业现场常需优先保障UDP实时流，这要求在驱动层支持tc qdisc，即MAC必须实现ndo_select_queue()回调，根据DSCP字段选择不同TX队列。

所以，一个合格的以太网驱动，不仅要让ifconfig显示UP，更要让ethtool -S eth0输出的rx_packets,tx_errors,rx_jabbers等计数器稳定增长，让tcpdump -i eth0 icmp能抓到干净的ICMP包，让iperf3 -c 192.168.1.1 -t 60跑满带宽且抖动<1ms。这才是“能用好”的标准。

3. 核心细节解析：寄存器配置、DMA管理与PHY调试的实战要点

3.1 MAC寄存器配置：从基础使能到高级特性调优

以STMicro的STMMAC为例，其核心寄存器组分为控制、DMA、MAC、PCS四大块。新手常犯的错误是只配MAC_CONFIGURATION（0x0000）和DMA_OPERATION_MODE（0x0018），却忽略三个致命寄存器：

• DMA_BUS_MODE（0x0004）：必须设置PRR（Programmable Rx/Tx Ring）位，否则DMA环无法启用；ATDS（Alternate Descriptor Size）位决定描述符是32位还是64位，ARM64平台必须置1；
• DMA_RX_WATCHDOG_TIMER（0x0014）：默认值0x00，表示禁用看门狗。但实际项目中，若PHY链路闪断，RX DMA可能卡死，需设为0x0100（100us超时），触发DMA_STATUS的RS（Rx Stopped）中断；
• MAC_VLAN_TAG（0x0070）：工业交换机常用VLAN隔离，此处需写入VID（如0x0001）并置VL位，否则VLAN标签帧会被MAC丢弃。

参数计算示例：DMA RX描述符环大小。假设系统需处理1000个并发连接，每个连接最大MTU=1500，则单个RX缓冲区需1536字节。若RAM紧张，可设环大小为64（2^6），但必须满足：环大小 × 缓冲区大小 ≤ 物理内存连续块。我用dma_alloc_coherent()申请时，发现size=64*1536=98304字节，但dma_alloc_coherent()返回NULL——查dmesg发现CMA区域只剩64KB。解决方案：改用dma_alloc_noncoherent()+手动dma_sync_single_for_cpu()，牺牲一点性能保功能。

3.2 DMA描述符环：双环结构与Cache一致性实战

STMMAC采用“双环”DMA架构：RX环存储接收到的帧信息，TX环存储待发送帧。每个描述符含4个32位字：

• status：OWN_BIT、LS（Last Segment）、FS（First Segment）等标志位；
• length：数据长度；
• buffer1：指向DMA缓冲区的物理地址；
• buffer2：扩展字段（如TSO分片信息）。

关键难点在Cache一致性。ARM Cortex-A系列有VIPT Cache，当CPU修改status位（如清OWN_BIT），而DMA控制器仍认为该描述符“属于自己”，就会造成数据错乱。正确做法：

1. 分配描述符内存时用dma_alloc_coherent()，确保物理地址与虚拟地址映射一致；
2. 修改status前调用dma_sync_single_for_device()；
3. DMA写入数据后，CPU读取前调用dma_sync_single_for_cpu()。

我曾在一个RK3399项目中，因忘记dma_sync_single_for_cpu()，导致skb_copy_to_linear_data()拷贝到一半的帧数据，Wireshark抓包显示“Malformed Packet”。调试方法：在stmmac_rx()开头加printk("RX desc %d status=0x%x\n", i, rx_desc->status);，观察OWN_BIT是否及时清零。

3.3 PHY调试：用ethtool和mdio-tool定位物理层问题

当ifconfig eth0 up后link detected: no，别急着改驱动，先用工具分层排查：

• Layer 1（物理层）：ethtool eth0查看Link detected: no，说明PHY没连通。此时：

  • 用万用表测RJ45的TD+/TD-/RD+/RD-对地电压，正常应为±1.5V；
  • 用示波器看MDIO总线波形，确认MDC时钟频率和MDIO数据翻转；
  • 执行mdio-tool -d /dev/mdio0 -a 0x0 -r 0x00读PHY ID寄存器，返回0xffff即总线故障。

• Layer 2（数据链路层）：Link detected: yes但Speed: Unknown!，说明自协商失败。此时：

  • ethtool -s eth0 speed 100 duplex full autoneg off强制设速，若成功则证明PHY协商逻辑有问题；
  • 查PHY寄存器BMCR（0x00）：bit12=1表示自协商使能，bit13=1表示重启协商；
  • 写BMCR为0x3100（100BASE-TX全双工强制模式），再读BMSR（0x01）确认bit2=1（Link Status）。

• Layer 3（网络层）：能ping通但iperf3吞吐量只有理论值的30%，大概率是TX DMA瓶颈。ethtool -S eth0看tx_underflow_errors计数器，若持续增长，说明TX描述符环太小或CPU处理太慢，需增大环大小或优化中断合并（ethtool -C eth0 rx-usecs 50）。

3.4 设备树（DTS）配置：从引脚复用到时钟树的完整清单

设备树是以太网驱动的“硬件说明书”，错一处就全盘皆输。以i.MX6ULL为例，关键节点必须包含：

&iomuxc { pinctrl_enet: enetgrp { fsl,pins = < MX6UL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 MX6UL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 MX6UL_PAD_ENET_RGMII_TXC__ENET_RGMII_TXC 0x1b0b0 MX6UL_PAD_ENET_RGMII_TD0__ENET_RGMII_TD0 0x1b0b0 MX6UL_PAD_ENET_RGMII_TD1__ENET_RGMII_TD1 0x1b0b0 MX6UL_PAD_ENET_RGMII_TD2__ENET_RGMII_TD2 0x1b0b0 MX6UL_PAD_ENET_RGMII_TD3__ENET_RGMII_TD3 0x1b0b0 MX6UL_PAD_ENET_RGMII_TX_CTL__ENET_RGMII_TX_CTL 0x1b0b0 MX6UL_PAD_ENET_RGMII_RXC__ENET_RGMII_RXC 0x1b0b0 MX6UL_PAD_ENET_RGMII_RD0__ENET_RGMII_RD0 0x1b0b0 MX6UL_PAD_ENET_RGMII_RD1__ENET_RGMII_RD1 0x1b0b0 MX6UL_PAD_ENET_RGMII_RD2__ENET_RGMII_RD2 0x1b0b0 MX6UL_PAD_ENET_RGMII_RD3__ENET_RGMII_RD3 0x1b0b0 MX6UL_PAD_ENET_RGMII_RX_CTL__ENET_RGMII_RX_CTL 0x1b0b0 >; }; }; &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; phy-mode = "rgmii-id"; // 注意：id表示internal delay，需PHY支持 phy-handle = <&phy0>; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; // 复位引脚 phy-reset-duration = <10>; // 复位保持时间(ms) clocks = <&clks IMX6UL_CLK_ENET>, <&clks IMX6UL_CLK_ENET_AHB>; clock-names = "ipg", "ahb"; status = "okay"; };

重点说明：

• phy-mode必须与硬件匹配：rgmii（外部延时）、rgmii-id（内部延时）、rmii（精简接口）；
• phy-reset-gpios的GPIO号要查芯片手册，i.MX6ULL的GPIO1_IO25对应PAD_ENET_CRS_DV；
• clocks必须包含IPG（内核时钟）和AHB（总线时钟），缺一则DMA无法工作；
• status = "okay"是使能开关，注释掉就等于删除该设备。

4. 实操过程：从零构建一个可商用的以太网驱动模块

4.1 环境准备：交叉编译链与内核源码的精准匹配

别用网上随便下载的arm-linux-gnueabihf-gcc，必须和目标板内核版本严格对应。我推荐的做法：

1. 从板卡厂商SDK中提取toolchain目录，如/opt/fsl-imx-x11/4.14-sumo/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/；
2. 解压内核源码（如linux-imx_4.14.98），进入目录执行：

   make ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- imx_v7_defconfig make ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- menuconfig # 启用：Device Drivers → Network device support → Ethernet driver support → STMicroelectronics devices → STMMAC Ethernet driver make ARCH=arm CROSS_COMPILE=arm-poky-linux-gnueabi- -j$(nproc)

3. 编译生成drivers/net/ethernet/stmicro/stmmac/stmmac.ko，注意：CONFIG_STMMAC_ETH=m必须为模块，否则无法动态加载调试。

验证交叉编译正确性：file stmmac.ko应显示ARM aarch64，而非x86_64；arm-poky-linux-gnueabi-readelf -h stmmac.ko | grep 'Machine'输出ARM。

4.2 驱动框架搭建：基于Platform Device的模块化设计

不要直接修改内核源码，而是写独立ko模块。核心文件结构：

stmmac_custom/ ├── Makefile ├── stmmac_custom.c └── stmmac_custom.h

Makefile内容：

obj-m += stmmac_custom.o KDIR := /path/to/kernel/source PWD := $(shell pwd) all: make -C $(KDIR) M=$(PWD) modules clean: make -C $(KDIR) M=$(PWD) clean

stmmac_custom.c骨架：

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/of.h> #include <linux/of_address.h> #include <linux/of_irq.h> #include <linux/of_net.h> #include <linux/phy.h> #include "stmmac_custom.h" static const struct of_device_id stmmac_custom_of_match[] = { { .compatible = "st,stmmac-custom" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, stmmac_custom_of_match); static int stmmac_custom_probe(struct platform_device *pdev) { struct device_node *np = pdev->dev.of_node; struct resource *res; void __iomem *ioaddr; int irq, ret; // 1. 获取寄存器地址 res = platform_get_resource(pdev, IORESOURCE_MEM, 0); ioaddr = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(ioaddr)) return PTR_ERR(ioaddr); // 2. 获取中断号 irq = platform_get_irq(pdev, 0); if (irq < 0) return irq; // 3. 从设备树读取PHY地址 int phy_addr = of_get_phy_id(np); if (phy_addr < 0) { dev_err(&pdev->dev, "Failed to get phy id\n"); return -ENODEV; } // 4. 初始化MAC（调用stmmac库函数） ret = stmmac_dvr_probe(&pdev->dev, &stmmac_hlpi, ioaddr, res->start, irq, phy_addr, NULL); if (ret) return ret; return 0; } static struct platform_driver stmmac_custom_driver = { .probe = stmmac_custom_probe, .remove = stmmac_dvr_remove, .driver = { .name = "stmmac-custom", .of_match_table = stmmac_custom_of_match, }, }; module_platform_driver(stmmac_custom_driver); MODULE_LICENSE("GPL");

关键点：stmmac_dvr_probe()是内核提供的通用入口，我们只需封装硬件资源，避免重复造轮子。

4.3 设备树集成：为自定义驱动添加compatible节点

在板级DTS文件（如imx6ull-14x14-evk.dts）中添加：

&iomuxc { pinctrl_stmmac: stmmacgrp { fsl,pins = < MX6UL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0 MX6UL_PAD_ENET_MDC__ENET_MDC 0x1b0b0 // ... 其他引脚同前 >; }; }; &fec1 { compatible = "st,stmmac-custom"; // 关键！匹配驱动of_match_table pinctrl-names = "default"; pinctrl-0 = <&pinctrl_stmmac>; phy-mode = "rgmii-id"; phy-handle = <&phy0>; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; phy-reset-duration = <10>; clocks = <&clks IMX6UL_CLK_ENET>, <&clks IMX6UL_CLK_ENET_AHB>; clock-names = "ipg", "ahb"; status = "okay"; };

加载流程：insmod stmmac_custom.ko→ 内核匹配compatible→ 调用stmmac_custom_probe()→ 完成初始化。

4.4 功能验证：从底层寄存器到上层应用的全链路测试

测试必须分层进行，每层通过才进下一层：

特别提醒：iperf3测试时，服务端必须用iperf3 -s -i 1，客户端用-c，否则TCP窗口协商异常。我曾因服务端没加-i 1，误判为驱动性能问题，实际是iperf3默认30秒汇总一次，掩盖了瞬时抖动。

5. 常见问题与排查技巧实录：调试日志、示波器抓包与产线快速定位法

5.1 日志分析：读懂dmesg里的每一行警告

dmesg | grep -i "eth\|phy\|mdio"是第一道防线，但很多警告被新手忽略：

• stmmac: Failed to reset the device：MAC软复位失败，检查MAC_CONFIGURATION寄存器bit15（SW Reset）是否置1后等待足够时间（>10us）；
• phy phy-1:00: attached PHY driver [Generic PHY]：PHY驱动加载成功，但[Generic PHY]说明没加载专用驱动（如realtek），可能功能受限；
• stmmac: No suitable DMA descriptor available：RX描述符环满，需增大rx_ring_size或优化SKB释放速度；
• eth0: link down：PHY链路中断，结合ethtool eth0看Link detected: no，再查PHY寄存器BMSRbit2=0。

我的日志分析法：把dmesg输出重定向到文件，用vim打开，搜索ERROR、FAIL、timeout，然后顺着报错行向上看10行，找初始化序列的断点。比如看到mdio_read failed，就往前找stmmac_mdio_register()调用，确认MDIO总线注册是否成功。

5.2 示波器抓包：用物理信号验证协议行为

当软件日志无法定位时，示波器是终极武器。必测三点：

• REF_CLK：探头接ENET_REF_CLK引脚，设置时基100ns/div，观察波形是否稳定正弦，峰峰值是否2.5V±0.5V，抖动是否<1ps；
• MDIO总线：MDC为时钟，MDIO为双向数据线。用逻辑分析仪捕获MDIO波形，解码为IEEE 802.3 Clause 22协议，确认PHY地址、寄存器地址、读写操作是否符合预期；
• RGMII信号：TD0~TD3、TX_CTL、TXC为发送信号。用4通道示波器同步捕获，验证建立/保持时间（Setup/Hold Time）是否满足PHY datasheet要求（通常>1ns）。

经典案例：某项目RGMII发送数据错乱，示波器发现TXC相位比TD信号晚0.8ns，原因是PCB走线长度差2cm。解决方案：在设备树phy-mode = "rgmii-rxid"（接收端加内部延时），或调整PCB Layout。

5.3 产线快速定位法：三分钟故障分级表

面对产线批量不良，必须有标准化流程。我制定的《以太网故障三级分类表》：

此表已用于我负责的5条产线，平均故障定位时间从2小时缩短至8分钟。

5.4 独家避坑技巧：那些Datasheet不会写的“潜规则”

• PHY Reset脉冲宽度：多数PHY要求>100ns，但RTL8211F实测需>500ns，否则偶发初始化失败。我的做法：GPIO复位后udelay(1000)，比msleep(1)更精准；
• RGMII TX Delay：当使用rgmii-id模式时，PHY内部延迟仅补偿TX，RX仍需外部延时。必须在PCB上为RX信号线增加蛇形走线（长度≈1.5ns×15cm/ns=22.5cm），否则1000Mbps下误码率飙升；
• Linux内核版本陷阱：4.14内核的stmmac驱动不支持tx_tstamp（发送时间戳），若需PTP，必须升级到5.4+；
• 国产PHY兼容性：KSZ8081RNXIA在Linux 4.19+需打补丁才能识别，否则phy_connect()返回-ENODEV，补丁内容是添加ksz8081到micrel_phy_ids[]数组。

最后分享个小技巧：在驱动probe函数末尾加一行`printk(KERN_INFO "STMMAC Custom Driver Loaded Successfully