Linux下USB转串口：不是“插上就能用”，而是“看懂才能稳”
你有没有遇到过这样的场景？
调试一块新焊好的STM32开发板，手边是那根用了三年、外壳磨得发亮的CH340转接线——lsusb里清清楚楚写着ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter，可一敲ls /dev/ttyU*，空空如也；dmesg | tail里连个“ch341”影子都没有。你换端口、换线、重启、拔插十次……最后默默掏出Windows笔记本，设备管理器里绿标一闪，COM5稳稳就位。
这不是硬件坏了，也不是你手残了。这是Linux在用它自己的方式提醒你：USB转串口从来不是即插即用的魔法，而是一场内核、驱动、固件与权限规则共同参与的精密协作。
今天，我们不列命令，不贴报错截图，也不说“sudo modprobe ch341 就好了”。我们来拆开这个协作链条，看清每一环怎么咬合、哪里容易卡死、为什么有些设备在Ubuntu上秒认，在OpenWrt里却像消失了一样。
那个/dev/ttyUSB0是怎么凭空冒出来的？
先忘掉“驱动安装”这个词。Linux内核里没有“安装”这回事——只有识别、匹配、初始化、注册、暴露。
当你把CH340插入USB口，物理层握手完成后，内核做的第一件事是读它的USB描述符。重点不是它叫什么，而是三个数字：
idVendor（厂商ID）：0x1a86—— 南京沁恒idProduct（产品ID）：0x7523—— CH340G的经典PIDbDeviceClass：0xff—— 关键！这不是标准CDC类（0x02），而是“厂商自定义”，意味着：通用驱动cdc_acm直接跳过它。
这时，内核的usbcore模块会遍历所有已注册的USB设备驱动，挨个问：“这个0x1a86:0x7523，归你管吗？”
直到它碰到ch341.ko驱动里这张表：
static const struct usb_device_id id_table[] = { { USB_DEVICE(0x1a86, 0x7523) }, // 看，就这一行，锁死了归属 { USB_DEVICE(0x1a86, 0x5523) }, // CH341也归它 { } };匹配成功，ch341_driver.probe()被调用。它不直接读写CH340寄存器，而是调用usb_serial_probe()—— 这才是真正的分层精髓：芯片驱动只负责“怎么跟CH340说话”（比如发0x9A控制码设波特率），而“怎么把数据塞进TTY接口”这件事，交给更上层的usbserial框架统一处理。
最终，
