Documentation/hwmon/submitting-patches.rst

Source file repositories/reference/linux-study-clean/Documentation/hwmon/submitting-patches.rst

File Facts

System
Linux kernel
Corpus path
Documentation/hwmon/submitting-patches.rst
Extension
.rst
Size
7091 bytes
Lines
153
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

How to Get Your Patch Accepted Into the Hwmon Subsystem
=======================================================

This text is a collection of suggestions for people writing patches or
drivers for the hwmon subsystem. Following these suggestions will greatly
increase the chances of your change being accepted.


1. General
----------

* It should be unnecessary to mention, but please read and follow:

    - Documentation/process/submit-checklist.rst
    - Documentation/process/submitting-patches.rst
    - Documentation/process/coding-style.rst

* Please run your patch through 'checkpatch --strict'. There should be no
  errors, no warnings, and few if any check messages. If there are any
  messages, please be prepared to explain.

* Please use the standard multi-line comment style. Do not mix C and C++
  style comments in a single driver (with the exception of the SPDX license
  identifier).

* If your patch generates checkpatch errors, warnings, or check messages,
  please refrain from explanations such as "I prefer that coding style".
  Keep in mind that each unnecessary message helps hiding a real problem,
  and a consistent coding style makes it easier for others to understand
  and review the code.

* Please test your patch thoroughly. We are not your test group.
  Sometimes a patch can not or not completely be tested because of missing
  hardware. In such cases, you should test-build the code on at least one
  architecture. If run-time testing was not achieved, it should be written
  explicitly below the patch header.

* If your patch (or the driver) is affected by configuration options such as
  CONFIG_SMP, make sure it compiles for all configuration variants.


2. Adding functionality to existing drivers
-------------------------------------------

* Make sure the documentation in Documentation/hwmon/<driver_name>.rst is up to
  date.

* Make sure the information in Kconfig is up to date.

* If the added functionality requires some cleanup or structural changes, split
  your patch into a cleanup part and the actual addition. This makes it easier
  to review your changes, and to bisect any resulting problems.

* Never mix bug fixes, cleanup, and functional enhancements in a single patch.


3. New drivers
--------------

* Running your patch or driver file(s) through checkpatch does not mean its
  formatting is clean. If unsure about formatting in your new driver, run it
  through Lindent. Lindent is not perfect, and you may have to do some minor
  cleanup, but it is a good start.

* Consider adding yourself to MAINTAINERS.

* Document the driver in Documentation/hwmon/<driver_name>.rst.

* Add the driver to Kconfig and Makefile in alphabetical order.

Annotation

Implementation Notes