Commit | Line | Data |
---|---|---|
c3a2f0ad GR |
1 | How to Get Your Patch Accepted Into the Hwmon Subsystem |
2 | ------------------------------------------------------- | |
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 | ||
12 | * It should be unnecessary to mention, but please read and follow | |
13 | Documentation/SubmitChecklist | |
14 | Documentation/SubmittingDrivers | |
15 | Documentation/SubmittingPatches | |
16 | Documentation/CodingStyle | |
17 | ||
18 | * If your patch generates checkpatch warnings, please refrain from explanations | |
19 | such as "I don't like that coding style". Keep in mind that each unnecessary | |
20 | warning helps hiding a real problem. If you don't like the kernel coding | |
21 | style, don't write kernel drivers. | |
22 | ||
23 | * Please test your patch thoroughly. We are not your test group. | |
24 | Sometimes a patch can not or not completely be tested because of missing | |
25 | hardware. In such cases, you should test-build the code on at least one | |
26 | architecture. If run-time testing was not achieved, it should be written | |
27 | explicitly below the patch header. | |
28 | ||
29 | * If your patch (or the driver) is affected by configuration options such as | |
40b31360 | 30 | CONFIG_SMP, make sure it compiles for all configuration variants. |
c3a2f0ad GR |
31 | |
32 | ||
33 | 2. Adding functionality to existing drivers | |
34 | ------------------------------------------- | |
35 | ||
36 | * Make sure the documentation in Documentation/hwmon/<driver_name> is up to | |
37 | date. | |
38 | ||
39 | * Make sure the information in Kconfig is up to date. | |
40 | ||
41 | * If the added functionality requires some cleanup or structural changes, split | |
42 | your patch into a cleanup part and the actual addition. This makes it easier | |
43 | to review your changes, and to bisect any resulting problems. | |
44 | ||
45 | * Never mix bug fixes, cleanup, and functional enhancements in a single patch. | |
46 | ||
47 | ||
48 | 3. New drivers | |
49 | -------------- | |
50 | ||
51 | * Running your patch or driver file(s) through checkpatch does not mean its | |
52 | formatting is clean. If unsure about formatting in your new driver, run it | |
53 | through Lindent. Lindent is not perfect, and you may have to do some minor | |
54 | cleanup, but it is a good start. | |
55 | ||
56 | * Consider adding yourself to MAINTAINERS. | |
57 | ||
58 | * Document the driver in Documentation/hwmon/<driver_name>. | |
59 | ||
60 | * Add the driver to Kconfig and Makefile in alphabetical order. | |
61 | ||
07d33600 | 62 | * Make sure that all dependencies are listed in Kconfig. |
c3a2f0ad GR |
63 | |
64 | * Avoid forward declarations if you can. Rearrange the code if necessary. | |
65 | ||
66 | * Avoid calculations in macros and macro-generated functions. While such macros | |
67 | may save a line or so in the source, it obfuscates the code and makes code | |
68 | review more difficult. It may also result in code which is more complicated | |
69 | than necessary. Use inline functions or just regular functions instead. | |
70 | ||
3fafb0ce GR |
71 | * Use devres functions whenever possible to allocate resources. For rationale |
72 | and supported functions, please see Documentation/driver-model/devres.txt. | |
73 | ||
c3a2f0ad GR |
74 | * If the driver has a detect function, make sure it is silent. Debug messages |
75 | and messages printed after a successful detection are acceptable, but it | |
76 | must not print messages such as "Chip XXX not found/supported". | |
77 | ||
78 | Keep in mind that the detect function will run for all drivers supporting an | |
79 | address if a chip is detected on that address. Unnecessary messages will just | |
80 | pollute the kernel log and not provide any value. | |
81 | ||
82 | * Provide a detect function if and only if a chip can be detected reliably. | |
83 | ||
84 | * Avoid writing to chip registers in the detect function. If you have to write, | |
85 | only do it after you have already gathered enough data to be certain that the | |
86 | detection is going to be successful. | |
87 | ||
88 | Keep in mind that the chip might not be what your driver believes it is, and | |
89 | writing to it might cause a bad misconfiguration. | |
90 | ||
91 | * Make sure there are no race conditions in the probe function. Specifically, | |
92 | completely initialize your chip first, then create sysfs entries and register | |
93 | with the hwmon subsystem. | |
94 | ||
95 | * Do not provide support for deprecated sysfs attributes. | |
96 | ||
97 | * Do not create non-standard attributes unless really needed. If you have to use | |
98 | non-standard attributes, or you believe you do, discuss it on the mailing list | |
99 | first. Either case, provide a detailed explanation why you need the | |
100 | non-standard attribute(s). | |
101 | Standard attributes are specified in Documentation/hwmon/sysfs-interface. | |
102 | ||
103 | * When deciding which sysfs attributes to support, look at the chip's | |
104 | capabilities. While we do not expect your driver to support everything the | |
105 | chip may offer, it should at least support all limits and alarms. | |
106 | ||
107 | * Last but not least, please check if a driver for your chip already exists | |
108 | before starting to write a new driver. Especially for temperature sensors, | |
109 | new chips are often variants of previously released chips. In some cases, | |
110 | a presumably new chip may simply have been relabeled. |