如何将您的补丁提交到 Hwmon 子系统¶
本文档收集了针对为 hwmon 子系统编写补丁或驱动程序的人员的建议。遵循这些建议将大大提高您的更改被接受的机会。
1. 一般¶
无需赘言，但请阅读并遵循
请使用 ‘checkpatch --strict’ 运行您的补丁。不应有错误、警告，以及很少的检查消息。如果有任何消息，请准备好解释。
请使用标准的多行注释风格。请勿在单个驱动程序中混合使用 C 和 C++ 风格的注释（SPDX 许可证标识符除外）。
如果您的补丁生成了 checkpatch 错误、警告或检查消息，请避免诸如“我喜欢这种编码风格”之类的解释。请记住，每条不必要的消息都会帮助隐藏一个真正的问题，并且一致的编码风格使其他人更容易理解和审查代码。
请彻底测试您的补丁。我们不是您的测试组。有时由于缺少硬件，无法或不能完全测试补丁。在这种情况下，您至少应该在一个架构上测试构建代码。如果未实现运行时测试，则应在补丁标题下方明确写明。
如果您的补丁（或驱动程序）受到诸如 CONFIG_SMP 之类的配置选项的影响，请确保它能为所有配置变体编译。
2. 向现有驱动程序添加功能¶
确保 Documentation/hwmon/<driver_name>.rst 中的文档是最新的。
确保 Kconfig 中的信息是最新的。
如果添加的功能需要一些清理或结构性更改，请将您的补丁拆分为清理部分和实际添加部分。这使审查您的更改更容易，并且可以剖析任何由此产生的问题。
切勿在单个补丁中混合错误修复、清理和功能增强。
3. 新驱动程序¶
使用 checkpatch 运行您的补丁或驱动程序文件并不意味着其格式是干净的。如果您不确定新驱动程序中的格式，请使用 Lindent 运行它。Lindent 并不完美，您可能需要做一些小的清理工作，但它是一个很好的开始。
考虑将您自己添加到 MAINTAINERS。
在 Documentation/hwmon/<driver_name>.rst 中记录驱动程序。
按字母顺序将驱动程序添加到 Kconfig 和 Makefile。
确保所有依赖项都列在 Kconfig 中。
请按字母顺序排列包含文件。
请将续行与上一行的 ‘(’ 对齐。
如果可以，请避免前向声明。如有必要，请重新排列代码。
避免使用宏来生成传感器属性组。它不仅会混淆 checkpatch，还会使代码审查更加困难。
避免在宏和宏生成的函数中进行计算。虽然这样的宏可能会在源代码中节省一行左右，但它会使代码变得模糊，并使代码审查更加困难。它还可能导致代码比必要的更复杂。请改用内联函数或常规函数。
限制内核日志消息的数量。通常，您的驱动程序不应仅仅因为运行时操作失败而生成错误消息。请使用适当的错误代码将错误报告给用户空间。请记住，内核错误日志消息不仅会填满内核日志，而且会同步打印，很可能是在中断被禁用的情况下打印到串行控制台。过多的日志记录会严重影响系统性能。
尽可能使用 devres 函数来分配资源。有关理由和支持的函数，请参阅 Devres - 托管设备资源。如果 devres 不支持某个函数，请考虑使用 devm_add_action()。
如果驱动程序有一个检测函数，请确保它是静默的。成功检测后打印调试消息和消息是可以接受的，但它不能打印诸如“未找到/不支持芯片 XXX”之类的消息。
请记住，如果在该地址上检测到芯片，则检测函数将为所有支持该地址的驱动程序运行。不必要的消息只会污染内核日志，而不会提供任何价值。
仅当可以可靠地检测到芯片时才提供检测功能。
只能探测以下 I2C 地址：0x18-0x1f、0x28-0x2f、0x48-0x4f、0x58、0x5c、0x73 和 0x77。强烈不鼓励探测其他地址，因为它已知会导致其他（非 hwmon）I2C 芯片出现问题。如果您的芯片位于无法探测的地址，则必须显式实例化该设备（无论如何，这总是更好）。
避免在检测函数中写入芯片寄存器。如果您必须写入，请仅在您已经收集了足够的数据以确定检测将成功之后再执行此操作。
请记住，该芯片可能不是您的驱动程序认为的那样，并且向其写入可能会导致错误的配置。
确保 probe 函数中没有竞争条件。具体来说，首先完全初始化您的芯片和驱动程序，然后向 hwmon 子系统注册。
使用 devm_hwmon_device_register_with_info() 或，如果您的驱动程序需要 remove 函数，则使用 hwmon_device_register_with_info() 向 hwmon 子系统注册您的驱动程序。如果可能，请尝试使用 devm_add_action() 而不是 remove 函数。请勿使用任何已弃用的注册函数。
您的驱动程序应可以作为模块构建。如果不能，请准备好解释为什么必须将其构建到内核中。
请勿为已弃用的 sysfs 属性提供支持。
除非真正需要，否则请勿创建非标准属性。如果您必须使用非标准属性，或者您认为您需要使用非标准属性，请先在邮件列表中讨论。无论哪种情况，请详细说明为什么需要非标准属性。标准属性在 sysfs 文件的命名和数据格式标准中指定。
在决定支持哪些 sysfs 属性时，请查看芯片的功能。虽然我们不希望您的驱动程序支持芯片可能提供的所有功能，但它至少应支持所有限制和警报。
最后但并非最不重要的一点是，在开始编写新驱动程序之前，请检查您的芯片的驱动程序是否已存在。特别是对于温度传感器，新的芯片通常是以前发布的芯片的变体。在某些情况下，推测的新芯片可能只是被重新贴了标签。