编译Linux USB无线驱动报错：Void value not ignored as it ought to be

老兄我太懂这种啃TP-Link驱动代码的崩溃感了——他们的代码质量真的有时候让人扶额！针对你遇到的这个问题，咱们一步步来拆解：

1. 先搞清楚seq_printf的真实原型 #

首先，Linux内核标准里的seq_printf根本不是void类型，它的原型在<linux/seq_file.h>里，是：

int seq_printf(struct seq_file *m, const char *fmt, ...);

返回值是成功打印的字符数，失败时返回负数。你看到的“void类型”错误，大概率是因为驱动代码没正确包含头文件，或者存在宏定义冲突，导致编译器找不到正确的函数声明，甚至被错误定义成了void。

检查头文件 #

先确认你的驱动代码里有没有包含：

#include <linux/seq_file.h>

如果没有，加上它；如果已经有了，检查有没有其他头文件或者本地宏定义把seq_printf给覆盖成void了——比如有没有类似这样的错误定义：

#define seq_printf(...) do {} while(0)

2. 修复_seqdump宏的使用问题 #

如果确认seq_printf确实应该返回int，但代码里的判断逻辑没问题，那可能是驱动代码的兼容问题（比如针对老内核写的，但你用的是新内核？反过来也有可能）。如果是必须适配当前环境：

情况A：当前环境seq_printf有返回值（正常情况） #

那错误就是因为头文件没包含，导致编译器误判类型。加上<linux/seq_file.h>后，应该就能解决类型不匹配的问题。

情况B：某些特殊环境下seq_printf是void（极少情况） #

那你需要修改代码中所有使用_seqdump返回值的地方，比如把：

if (_seqdump(m, "Error: %d\n", err)) {
    // 处理错误
}

改成直接调用，去掉返回值判断：

_seqdump(m, "Error: %d\n", err);

如果原本的逻辑是判断打印是否成功，那可以换成其他方式（比如检查struct seq_file的状态），但这种情况非常罕见，优先排查头文件问题。

3. 额外提示：TP-Link驱动的常见坑 #

TP-Link的很多开源驱动都是基于老内核版本写的，和新内核的API有兼容性问题。如果这一步解决了，后续可能还会遇到其他API变更的问题（比如usb_submit_urb的返回值处理、无线子系统的API变化等），建议对照你当前使用的内核版本的文档，逐步修正这些兼容性问题。

内容的提问来源于stack exchange，提问作者Homunculus Reticulli