The GERRIT_CHANGE_ID Error is useful for the linux flow, but since
coreboot uses gerrit, giving an error on the ID doesn't make sense.
Change-Id: I7f6efb5559027ed9497ee85497bb4b4e786f9901
Signed-off-by: Martin Roth <martin@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Subrata Banik <subratabanik@google.com>
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>
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>
- 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>
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>
- 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>
- 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>
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>
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>
Elyes Haouas