Commit | Line | Data |
---|---|---|
b04f2f7d MCC |
1 | How to Get Your Patch Accepted Into the Hwmon Subsystem |
2 | ======================================================= | |
c3a2f0ad | 3 | |
ac20ad14 | 4 | This text is a collection of suggestions for people writing patches or |
c3a2f0ad GR |
5 | drivers for the hwmon subsystem. Following these suggestions will greatly |
6 | increase the chances of your change being accepted. | |
7 | ||
8 | ||
9 | 1. General | |
10 | ---------- | |
11 | ||
b04f2f7d MCC |
12 | * It should be unnecessary to mention, but please read and follow: |
13 | ||
14 | - Documentation/process/submit-checklist.rst | |
b04f2f7d MCC |
15 | - Documentation/process/submitting-patches.rst |
16 | - Documentation/process/coding-style.rst | |
c3a2f0ad | 17 | |
165720d9 GR |
18 | * Please run your patch through 'checkpatch --strict'. There should be no |
19 | errors, no warnings, and few if any check messages. If there are any | |
20 | messages, please be prepared to explain. | |
21 | ||
4e19e72f GR |
22 | * Please use the standard multi-line comment style. Do not mix C and C++ |
23 | style comments in a single driver (with the exception of the SPDX license | |
24 | identifier). | |
25 | ||
165720d9 GR |
26 | * If your patch generates checkpatch errors, warnings, or check messages, |
27 | please refrain from explanations such as "I prefer that coding style". | |
28 | Keep in mind that each unnecessary message helps hiding a real problem, | |
29 | and a consistent coding style makes it easier for others to understand | |
30 | and review the code. | |
c3a2f0ad GR |
31 | |
32 | * Please test your patch thoroughly. We are not your test group. | |
33 | Sometimes a patch can not or not completely be tested because of missing | |
34 | hardware. In such cases, you should test-build the code on at least one | |
35 | architecture. If run-time testing was not achieved, it should be written | |
36 | explicitly below the patch header. | |
37 | ||
38 | * If your patch (or the driver) is affected by configuration options such as | |
40b31360 | 39 | CONFIG_SMP, make sure it compiles for all configuration variants. |
c3a2f0ad GR |
40 | |
41 | ||
42 | 2. Adding functionality to existing drivers | |
43 | ------------------------------------------- | |
44 | ||
7ebd8b66 | 45 | * Make sure the documentation in Documentation/hwmon/<driver_name>.rst is up to |
c3a2f0ad GR |
46 | date. |
47 | ||
48 | * Make sure the information in Kconfig is up to date. | |
49 | ||
50 | * If the added functionality requires some cleanup or structural changes, split | |
51 | your patch into a cleanup part and the actual addition. This makes it easier | |
52 | to review your changes, and to bisect any resulting problems. | |
53 | ||
54 | * Never mix bug fixes, cleanup, and functional enhancements in a single patch. | |
55 | ||
56 | ||
57 | 3. New drivers | |
58 | -------------- | |
59 | ||
60 | * Running your patch or driver file(s) through checkpatch does not mean its | |
61 | formatting is clean. If unsure about formatting in your new driver, run it | |
62 | through Lindent. Lindent is not perfect, and you may have to do some minor | |
63 | cleanup, but it is a good start. | |
64 | ||
65 | * Consider adding yourself to MAINTAINERS. | |
66 | ||
7ebd8b66 | 67 | * Document the driver in Documentation/hwmon/<driver_name>.rst. |
c3a2f0ad GR |
68 | |
69 | * Add the driver to Kconfig and Makefile in alphabetical order. | |
70 | ||
07d33600 | 71 | * Make sure that all dependencies are listed in Kconfig. |
c3a2f0ad | 72 | |
165720d9 GR |
73 | * Please list include files in alphabetic order. |
74 | ||
75 | * Please align continuation lines with '(' on the previous line. | |
76 | ||
c3a2f0ad GR |
77 | * Avoid forward declarations if you can. Rearrange the code if necessary. |
78 | ||
165720d9 GR |
79 | * Avoid macros to generate groups of sensor attributes. It not only confuses |
80 | checkpatch, but also makes it more difficult to review the code. | |
81 | ||
c3a2f0ad GR |
82 | * Avoid calculations in macros and macro-generated functions. While such macros |
83 | may save a line or so in the source, it obfuscates the code and makes code | |
84 | review more difficult. It may also result in code which is more complicated | |
85 | than necessary. Use inline functions or just regular functions instead. | |
86 | ||
165720d9 GR |
87 | * Limit the number of kernel log messages. In general, your driver should not |
88 | generate an error message just because a runtime operation failed. Report | |
89 | errors to user space instead, using an appropriate error code. Keep in mind | |
90 | that kernel error log messages not only fill up the kernel log, but also are | |
91 | printed synchronously, most likely with interrupt disabled, often to a serial | |
92 | console. Excessive logging can seriously affect system performance. | |
93 | ||
3fafb0ce | 94 | * Use devres functions whenever possible to allocate resources. For rationale |
fe34c89d | 95 | and supported functions, please see Documentation/driver-api/driver-model/devres.rst. |
165720d9 | 96 | If a function is not supported by devres, consider using devm_add_action(). |
3fafb0ce | 97 | |
c3a2f0ad GR |
98 | * If the driver has a detect function, make sure it is silent. Debug messages |
99 | and messages printed after a successful detection are acceptable, but it | |
100 | must not print messages such as "Chip XXX not found/supported". | |
101 | ||
102 | Keep in mind that the detect function will run for all drivers supporting an | |
103 | address if a chip is detected on that address. Unnecessary messages will just | |
104 | pollute the kernel log and not provide any value. | |
105 | ||
106 | * Provide a detect function if and only if a chip can be detected reliably. | |
107 | ||
97607f98 JD |
108 | * Only the following I2C addresses shall be probed: 0x18-0x1f, 0x28-0x2f, |
109 | 0x48-0x4f, 0x58, 0x5c, 0x73 and 0x77. Probing other addresses is strongly | |
110 | discouraged as it is known to cause trouble with other (non-hwmon) I2C | |
111 | chips. If your chip lives at an address which can't be probed then the | |
112 | device will have to be instantiated explicitly (which is always better | |
113 | anyway.) | |
114 | ||
c3a2f0ad GR |
115 | * Avoid writing to chip registers in the detect function. If you have to write, |
116 | only do it after you have already gathered enough data to be certain that the | |
117 | detection is going to be successful. | |
118 | ||
119 | Keep in mind that the chip might not be what your driver believes it is, and | |
120 | writing to it might cause a bad misconfiguration. | |
121 | ||
122 | * Make sure there are no race conditions in the probe function. Specifically, | |
165720d9 GR |
123 | completely initialize your chip and your driver first, then register with |
124 | the hwmon subsystem. | |
125 | ||
9b0cffa6 GR |
126 | * Use devm_hwmon_device_register_with_info() or, if your driver needs a remove |
127 | function, hwmon_device_register_with_info() to register your driver with the | |
165720d9 GR |
128 | hwmon subsystem. Try using devm_add_action() instead of a remove function if |
129 | possible. Do not use hwmon_device_register(). | |
130 | ||
131 | * Your driver should be buildable as module. If not, please be prepared to | |
132 | explain why it has to be built into the kernel. | |
c3a2f0ad GR |
133 | |
134 | * Do not provide support for deprecated sysfs attributes. | |
135 | ||
136 | * Do not create non-standard attributes unless really needed. If you have to use | |
137 | non-standard attributes, or you believe you do, discuss it on the mailing list | |
138 | first. Either case, provide a detailed explanation why you need the | |
139 | non-standard attribute(s). | |
7ebd8b66 | 140 | Standard attributes are specified in Documentation/hwmon/sysfs-interface.rst. |
c3a2f0ad GR |
141 | |
142 | * When deciding which sysfs attributes to support, look at the chip's | |
143 | capabilities. While we do not expect your driver to support everything the | |
144 | chip may offer, it should at least support all limits and alarms. | |
145 | ||
146 | * Last but not least, please check if a driver for your chip already exists | |
147 | before starting to write a new driver. Especially for temperature sensors, | |
148 | new chips are often variants of previously released chips. In some cases, | |
149 | a presumably new chip may simply have been relabeled. |