Linux UART设备树配置4线模式时，为何CTS/RTS无效？

Question

在Linux设备树中配置UART使用4线模式（包含CTS/RTS硬件流控）时，常出现CTS/RTS无效的问题。典型表现为数据发送未受对端CTS信号控制，导致数据丢失或通信异常。常见原因包括：设备树中未正确设置`uart-has-rts-cts`属性，或遗漏`pinctrl`对CTS/RTS引脚的复用配置；此外，串口驱动未启用硬件流控支持（如未在`of_serial.c`中解析流控标志），或终端应用未通过`tcsetattr()`启用`CRTSCTS`标志，也会导致流控失效。需综合检查设备树、引脚控制和用户层配置。

Answer 1

Linux设备树中UART 4线模式（含CTS/RTS硬件流控）配置失效问题深度解析

1. 问题背景与典型现象

在嵌入式Linux系统开发中，UART通信广泛应用于调试、传感器数据采集和工业控制等场景。当波特率较高或通信环境复杂时，硬件流控（Hardware Flow Control）成为保障数据完整性的关键机制。典型的4线UART模式包括TX、RX、CTS（Clear To Send）和RTS（Request To Send），其中CTS信号由接收端控制，用于通知发送端是否可以继续发送数据。

然而，在实际部署中，常出现CTS/RTS信号未被正确响应的现象：尽管对端拉低CTS，发送端仍持续发送数据，导致接收缓冲区溢出、数据丢失或通信中断。此类问题具有隐蔽性强、排查难度高的特点，往往涉及设备树、引脚复用、驱动支持及用户空间配置多个层级。

2. 常见原因分类与排查路径

1. 设备树中未设置 uart-has-rts-cts 属性
2. pinctrl 节点未将 CTS/RTS 引脚配置为串口功能复用
3. 内核串口驱动未解析流控标志（如 of_serial.c 缺失相关逻辑）
4. 用户层应用未通过 tcsetattr() 启用 CRTSCTS 标志
5. 物理连接错误或电平不匹配（如 TTL vs RS232）
6. 对端设备未正确实现流控逻辑
7. 内核编译时禁用了硬件流控支持选项
8. DTSI 包含的默认 pinctrl 配置覆盖了自定义设置
9. 多路复用器（MUX）配置冲突
10. GPIO 子系统抢占了 CTS/RTS 引脚

3. 设备树配置检查清单

检查项	正确示例	常见错误
uart-has-rts-cts	uart-has-rts-cts;	完全缺失或拼写错误
pinctrl-names	pinctrl-names = "default";	使用 "sleep" 或其他非激活状态
pinctrl-0	pinctrl-0 = <&uart1_rts_cts_pins>;	指向错误的pin组或未定义
pinmux配置	uart1_rts_cts_pins: uart1-rts-cts { ... };	引脚复用功能号错误

4. 典型设备树片段示例

&uart1 {
    compatible = "fsl,imx6q-uart";
    reg = <0x2020000 0x1000>;
    interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&clks IMX6Q_CLK_UART1>;
    clock-names = "ipg", "per";
    uart-has-rts-cts;
    dmas = <&sdma 27 4 0>, <&sdma 28 4 0>;
    dma-names = "rx", "tx";
    pinctrl-names = "default";
    pinctrl-0 = <&uart1_rts_cts_pins>;
    status = "okay";
};

&pinctrl_uart1 {
    uart1_rts_cts_pins: uart1-rts-cts {
        fsl,pins = <
            MX6UL_PAD_UART1_RTS_B__UART1_RTS_B    0x1b0b1
            MX6UL_PAD_UART1_CTS_B__UART1_CTS_B    0x1b0b1
        >;
    };
};

    

5. 内核驱动层分析流程图

graph TD
            A[设备树解析] --> B{是否存在 uart-has-rts-cts?}
            B -- 是 --> C[调用 of_property_read_bool()]
            B -- 否 --> D[不启用硬件流控]
            C --> E[of_serial.c 设置 port->flags |= UPF_HARD_FLOW]
            E --> F[传递至串口驱动底层]
            F --> G[硬件自动处理 RTS/CTS]
            G --> H[发送前检测 CTS 电平]
            H --> I[仅当 CTS=高 时允许发送]

6. 用户空间启用硬件流控代码示例

即使内核层面配置正确，若用户程序未启用CRTSCTS标志，流控仍将无效。以下为标准C语言实现：

#include <termios.h>
#include <fcntl.h>

int fd = open("/dev/ttyLP1", O_RDWR | O_NOCTTY);
struct termios tty;

if (tcgetattr(fd, &tty) != 0) {
    // 错误处理
}

cfsetspeed(&tty, B115200);
tty.c_cflag |= CS8 | CLOCAL | CREAD;
tty.c_cflag &= ~PARENB;
tty.c_cflag &= ~CSTOPB;

// 关键：启用硬件流控
tty.c_cflag |= CRTSCTS;

if (tcsetattr(fd, TCSANOW, &tty) != 0) {
    // 设置失败
}

    

7. 调试与验证方法

• 使用 stty -F /dev/ttyLP1 -a 查看当前串口参数，确认 crtscts 是否启用
• 通过逻辑分析仪或示波器监测 CTS/RTS 引脚电平变化
• 插入打印语句到 drivers/tty/serial/of_serial.c 中确认属性解析结果
• 检查 /proc/device-tree 下对应节点是否存在 uart-has-rts-cts
• 使用 cat /sys/kernel/debug/pinctrl/<xxx>/pingroups 验证引脚复用状态
• 临时禁用DMA以排除缓冲区管理干扰
• 替换为简单轮询模式驱动进行对比测试
• 在对端强制拉低CTS并观察发送行为
• 启用内核串口调试日志（CONFIG_SERIAL_CORE_CONSOLE=y）
• 使用 strace 跟踪用户程序的 tcsetattr 系统调用

8. 内核配置依赖项

确保以下Kconfig选项已启用：

CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_IMX=y          # 或对应SoC驱动
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_GPIOLIB=y             # 若CTS/RTS涉及GPIO模拟（罕见）
    

部分老旧内核版本需手动补丁支持设备树流控属性解析，建议升级至4.19+长期支持版本。