linux-imx

​

​

    List of maintainers and how to submit kernel changes

​

Please try to follow the guidelines below.  This will make things

easier on the maintainers.  Not all of these guidelines matter for every

trivial patch so apply some common sense.

​

1.  Always _test_ your changes, however small, on at least 4 or

    5 people, preferably many more.

​

2.  Try to release a few ALPHA test versions to the net. Announce

    them onto the kernel channel and await results. This is especially

    important for device drivers, because often that's the only way

    you will find things like the fact version 3 firmware needs

    a magic fix you didn't know about, or some clown changed the

    chips on a board and not its name.  (Don't laugh!  Look at the

    SMC etherpower for that.)

​

3.  Make sure your changes compile correctly in multiple

    configurations. In particular check that changes work both as a

    module and built into the kernel.

​

4.  When you are happy with a change make it generally available for

    testing and await feedback.

​

5.  Make a patch available to the relevant maintainer in the list. Use

    'diff -u' to make the patch easy to merge. Be prepared to get your

    changes sent back with seemingly silly requests about formatting

    and variable names.  These aren't as silly as they seem. One

    job the maintainers (and especially Linus) do is to keep things

    looking the same. Sometimes this means that the clever hack in

    your driver to get around a problem actually needs to become a

    generalized kernel feature ready for next time.

​

    PLEASE check your patch with the automated style checker

    (scripts/checkpatch.pl) to catch trivial style violations.

    See Documentation/process/coding-style.rst for guidance here.

​

    PLEASE CC: the maintainers and mailing lists that are generated

    by scripts/get_maintainer.pl.  The results returned by the

    script will be best if you have git installed and are making

    your changes in a branch derived from Linus' latest git tree.

    See Documentation/process/submitting-patches.rst for details.

​

    PLEASE try to include any credit lines you want added with the

    patch. It avoids people being missed off by mistake and makes

    it easier to know who wants adding and who doesn't.

​

    PLEASE document known bugs. If it doesn't work for everything

    or does something very odd once a month document it.

​

    PLEASE remember that submissions must be made under the terms

    of the Linux Foundation certificate of contribution and should

    include a Signed-off-by: line.  The current version of this

    "Developer's Certificate of Origin" (DCO) is listed in the file

    Documentation/process/submitting-patches.rst.

​

6.  Make sure you have the right to send any changes you make. If you

    do changes at work you may find your employer owns the patch

    not you.

​

7.  When sending security related changes or reports to a maintainer

    please Cc: security@kernel.org, especially if the maintainer

    does not respond. Please keep in mind that the security team is

    a small set of people who can be efficient only when working on

    verified bugs. Please only Cc: this list when you have identified

    that the bug would present a short-term risk to other users if it

    were publicly disclosed. For example, reports of address leaks do

    not represent an immediate threat and are better handled publicly,

    and ideally, should come with a patch proposal. Please do not send

    automated reports to this list either. Such bugs will be handled

    better and faster in the usual public places.

​

8.  Happy hacking.

​

Descriptions of section entries:

​

    P: Person (obsolete)

    M: Mail patches to: FullName <address@domain>

    R: Designated reviewer: FullName <address@domain>

       These reviewers should be CCed on patches.

    L: Mailing list that is relevant to this area

    W: Web-page with status/info

    B: URI for where to file bugs. A web-page with detailed bug

       filing info, a direct bug tracker link, or a mailto: URI.

    C: URI for chat protocol, server and channel where developers

       usually hang out, for example irc://server/channel.

    Q: Patchwork web based patch tracking system site

    T: SCM tree type and location.

       Type is one of: git, hg, quilt, stgit, topgit

    S: Status, one of the following: