[ARM] pxa/littleton: add UART3 GPIO config
[zen-stable.git] / Documentation / SubmitChecklist
blob1053a56be3b180c8ce202380ed9e882b5d97914a
1 Linux Kernel patch submission checklist
2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 Here are some basic things that developers should do if they want to see their
5 kernel patch submissions accepted more quickly.
7 These are all above and beyond the documentation that is provided in
8 Documentation/SubmittingPatches and elsewhere regarding submitting Linux
9 kernel patches.
12 1: Builds cleanly with applicable or modified CONFIG options =y, =m, and
13    =n.  No gcc warnings/errors, no linker warnings/errors.
15 2: Passes allnoconfig, allmodconfig
17 3: Builds on multiple CPU architectures by using local cross-compile tools
18    or some other build farm.
20 4: ppc64 is a good architecture for cross-compilation checking because it
21    tends to use `unsigned long' for 64-bit quantities.
23 5: Check your patch for general style as detailed in
24    Documentation/CodingStyle.  Check for trivial violations with the
25    patch style checker prior to submission (scripts/checkpatch.pl).
26    You should be able to justify all violations that remain in
27    your patch.
29 6: Any new or modified CONFIG options don't muck up the config menu.
31 7: All new Kconfig options have help text.
33 8: Has been carefully reviewed with respect to relevant Kconfig
34    combinations.  This is very hard to get right with testing -- brainpower
35    pays off here.
37 9: Check cleanly with sparse.
39 10: Use 'make checkstack' and 'make namespacecheck' and fix any problems
40     that they find.  Note: checkstack does not point out problems explicitly,
41     but any one function that uses more than 512 bytes on the stack is a
42     candidate for change.
44 11: Include kernel-doc to document global kernel APIs.  (Not required for
45     static functions, but OK there also.) Use 'make htmldocs' or 'make
46     mandocs' to check the kernel-doc and fix any issues.
48 12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
49     CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
50     CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
51     enabled.
53 13: Has been build- and runtime tested with and without CONFIG_SMP and
54     CONFIG_PREEMPT.
56 14: If the patch affects IO/Disk, etc: has been tested with and without
57     CONFIG_LBDAF.
59 15: All codepaths have been exercised with all lockdep features enabled.
61 16: All new /proc entries are documented under Documentation/
63 17: All new kernel boot parameters are documented in
64     Documentation/kernel-parameters.txt.
66 18: All new module parameters are documented with MODULE_PARM_DESC()
68 19: All new userspace interfaces are documented in Documentation/ABI/.
69     See Documentation/ABI/README for more information.
70     Patches that change userspace interfaces should be CCed to
71     linux-api@vger.kernel.org.
73 20: Check that it all passes `make headers_check'.
75 21: Has been checked with injection of at least slab and page-allocation
76     failures.  See Documentation/fault-injection/.
78     If the new code is substantial, addition of subsystem-specific fault
79     injection might be appropriate.
81 22: Newly-added code has been compiled with `gcc -W' (use "make
82     EXTRA_CFLAGS=-W").  This will generate lots of noise, but is good for
83     finding bugs like "warning: comparison between signed and unsigned".
85 23: Tested after it has been merged into the -mm patchset to make sure
86     that it still works with all of the other queued patches and various
87     changes in the VM, VFS, and other subsystems.
89 24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the
90     source code that explains the logic of what they are doing and why.
92 25: If any ioctl's are added by the patch, then also update
93     Documentation/ioctl/ioctl-number.txt.