GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/.checkpatch.conf

40 lines
1.1 KiB
Plaintext
Raw Normal View History

checkpatch: add .checkpatch.conf Try to make checkpatch a little friendlier to the coreboot project. This is the checkpatch .conf from the Chrome OS tree. Change-Id: Ie45d5c93f97bd58f3ea31341b47c4ee2a8f02b1e Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://review.coreboot.org/15919 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2016-07-27 19:56:32 +02:00
# Not Linux, so don't expect a Linux tree.
--no-tree
# Ignore aspects we don't follow here.
--ignore C99_COMMENTS
--ignore GLOBAL_INITIALISERS
--ignore INITIALISED_STATIC
--ignore LINE_SPACING
--ignore NEW_TYPEDEFS
--ignore PREFER_ALIGNED
--ignore PREFER_PACKED
--ignore PREFER_PRINTF
--ignore SPLIT_STRING
checkpatch: Add BLOCK_COMMENT_STYLE to ignore list Linux' newest checkpatch.pl flags comments like these: /* This is a concise 2-line comment that explains what the code does in * sufficient detail without wasting too much vertical space. */ do_stuff_that_needs_explaining(); Comments like these have been used in our code base for a long time and I don't think we should disallow them now. Ending the comment on the same line doesn't really hurt readability and wastes less screen real estate (which in turn usually helps overall code comprehension). Change-Id: Ifd57f3d3a62738165024cb4b2e75a4f815a57922 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16060 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-08-04 05:07:35 +02:00
--ignore BLOCK_COMMENT_STYLE
Update .checkpatch.conf - Don't require a description of every config statement in the Kconfig changes - Don't complain about externs in .c files - Don't complain about the use of the volatile keyword. The kernel may not want it, but we definitely need it. - Disable checks that seem to be broken. Change-Id: Ic419b81cd36852a91e887e610d4a04984ab5fbd7 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16010 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-08-01 21:21:30 +02:00
--ignore AVOID_EXTERNS
--ignore VOLATILE
--ignore CONFIG_DESCRIPTION
checkpatch.conf: Update rules - Remove the "MISSING_SPACE" check which checks for breaks at a space in a string concatenation. Most of the time this makes sense, but we occasionally need to break where there isn't a space, so having a hard rule doesn't always work. - Don't check the vendorcode directory for compliance to coreboot's code format rules. Change-Id: Ic07677b19520b5d22363834c77f5dee7bba9e429 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18569 Tested-by: build bot (Jenkins) Reviewed-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-03-05 02:51:16 +01:00
--ignore MISSING_SPACE
.checkpatch.conf: Ignore CORRUPTED_PATCH lint This lint makes lines like the following (trap_handler.c:30) uncommitable: printk(BIOS_DEBUG, "Getting hart id...\n"); The significant part of the line seems to be `\n")`. Change-Id: Id854ebcef11d8188aea707b8f3e988c704721bf5 Reported-by: Maximilian Schander <maxschander@googlemail.com> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/22202 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Maximilian Schander <maxschander@googlemail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
2017-10-28 02:03:06 +02:00
--ignore CORRUPTED_PATCH
.checkpatch.conf: Ignore a few more warnings - PRINTK_WITHOUT_KERN_LEVEL is a new warning that coreboot's printks don't follow. - UNDOCUMENTED_DT_STRING is ignored because we don't have any documentation for .dt files. - SPDX_LICENSE_TAG is another new warning. We can evaluate adding the spdx license tags to our files, but at this point they aren't there, so disable it for now. Change-Id: I4b7fcfc0339b358a48e77188d85b47c022c7eb49 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/28044 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-08-11 05:00:28 +02:00
--ignore SPDX_LICENSE_TAG
--ignore UNDOCUMENTED_DT_STRING
--ignore PRINTK_WITHOUT_KERN_LEVEL
lint: checkpatch: Ignore ASSIGN_IN_IF and UNNECESSARY_ELSE errors This patch disables checkpatch warnings about two style constructs that are not illegal in coreboot style and can in my opinion be useful in certain situations. The first is an assignment in if conditions like this: if ((ret = func())) return ret; This can save a line compared to the alternative construct which may help readability, especially in functions that need to do a lot of these. More importantly, the while-equivalent of this construct is not forbidden (and a lot more useful, because certain things become very complicated to write without it), and it seems weird to forbid one but not the other. We already have GCC warnings that enforce an extra set of parenthesis to highlight that this is an assignment instead of a comparison, so the risk of typos or confusion between those two is already mitigated anyway. The second is the use of `else` after return like this: if (CONFIG(TYPE_A)) return response_for_type_a; else return response_for_type_b; While the else is redundant in this case, it serves to highlight the symmetry and equivalence in importance of the two paths. There are certainly other situations where the construct of if (something_went_wrong) return error; if (something_else_went_wrong) return other_error; if (...) is more useful, but this usually suggests an "either abort here or continue on the main path" style flow, whereas the code with `else` is more suitable to highlight an "either one or the other" flow with two equal-weighted options. I think the programmer should pick which style best represents the intentions of their code in these cases, and don't understand why one of the two should be categorically forbidden. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I130598057c1800277a129ae6b927e961d6e26e42 Reviewed-on: https://review.coreboot.org/c/coreboot/+/51551 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-16 23:59:01 +01:00
--ignore ASSIGN_IN_IF
--ignore UNNECESSARY_ELSE
Update .checkpatch.conf - Don't require a description of every config statement in the Kconfig changes - Don't complain about externs in .c files - Don't complain about the use of the volatile keyword. The kernel may not want it, but we definitely need it. - Disable checks that seem to be broken. Change-Id: Ic419b81cd36852a91e887e610d4a04984ab5fbd7 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16010 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-08-01 21:21:30 +02:00
# FILE_PATH_CHANGES seems to not be working correctly. It will
# choke on added / deleted files even if the MAINTAINERS file
# is touched.
--ignore FILE_PATH_CHANGES
# This one has a linux path hard coded, so it would choke on
# some commits unnecessarily.
--ignore EXECUTE_PERMISSIONS
checkpatch.conf: Update rules - Remove the "MISSING_SPACE" check which checks for breaks at a space in a string concatenation. Most of the time this makes sense, but we occasionally need to break where there isn't a space, so having a hard rule doesn't always work. - Don't check the vendorcode directory for compliance to coreboot's code format rules. Change-Id: Ic07677b19520b5d22363834c77f5dee7bba9e429 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18569 Tested-by: build bot (Jenkins) Reviewed-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
2017-03-05 02:51:16 +01:00
lint: checkpatch: Only exclude specific src/vendorcode/ subdirectories Some of the src/vendorcode/ directories are used to import a whole codebase from somewhere else which uses a completely different coding style. For those directories, excluding them from checkpatch makes sense. However, other directories are simply implementing vendor-specific extensions that were written by coreboot developers specifically for coreboot in coreboot's coding style. Those directories should be covered by checkpatch. This patch narrows the existing blanket exception of src/vendorcode/ to the amd, cavium, intel and mediatek directories (which actually include large amounts of foreign source). The eltan, google and siemens directories (which seem to contain code specifically written for coreboot) will now be covered by checkpatch. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I1feaba37c469714217fff4d160e595849e0230b9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/51827 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-03-25 22:44:37 +01:00
# Exclude vendorcode directories that don't follow coreboot's coding style.
--exclude src/vendorcode/amd
--exclude src/vendorcode/cavium
--exclude src/vendorcode/intel
--exclude src/vendorcode/mediatek