Parse each empty-line-delimited message separately. This saves having to
deal with all the different line content styles, we only care about the
header ERROR | WARNING | NOTE...

Also make checkpatch print line information for a uboot specific
warning.

Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Given that we have tests that require pygit2 and it can be installed
like any other python module, fail much more loudly if it is missing.

Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>

strn(cat|cpy) has a bad habit of not nul-terminating the destination,
resulting in constructions like

	strncpy(foo, bar, sizeof(foo) - 1);
	foo[sizeof(foo) - 1] = '\0';

However, it is very easy to forget about this behavior and accidentally
leave a string unterminated. This has shown up in some recent coverity
scans [1, 2] (including code recently touched by yours truly).

Fortunately, the guys at OpenBSD came up with strl(cat|cpy), which always
nul-terminate strings. These functions are already in U-Boot, so we should
encourage new code to use them instead of strn(cat|cpy).

[1] https://lists.denx.de/pipermail/u-boot/2021-March/442888.html
[2] https://lists.denx.de/pipermail/u-boot/2021-January/438073.html

Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

While we cannot know which commit the warning relates to, this should not
be fatal. Print the warning and carry on.

Signed-off-by: Simon Glass <sjg@chromium.org>

At present, before any entry expansion is done (such as a 'files' entry
expanding out to individual entries for each file it contains), we check
the binman definition (i.e. '/binman' node) to find out what devicetree
files are used in the images.

This is a pain, since the definition may change during expansion. For
example if there is no u-boot-spl-dtb entry in the definition at the start,
we assume that the SPL devicetree is not used. But if an entry later
expands to include this, then we don't notice.

In fact the flexibility provided by the current approach of checking the
definition is not really useful. We know that we can have SPL and TPL
devicetrees. We know the pathname to each, so we can simply check if the
files are present. If they are present, we can prepare them and update
them regardless of whether they are actually used. If they are not present,
we cannot prepare/update them anyway, i.e. an error will be generated.

Simplify state.Prepare() so it uses a hard-coded list of devicetree files.

Note that state.PrepareFromLoadedData() is left untouched, since in that
case we have a complete definition from the loaded file, but cannot of
course rely on the devicetree files that created it still being present.
So in that case we still check the image defitions.

Signed-off-by: Simon Glass <sjg@chromium.org>

It's convenient to be able to scroll up in `patman -H`.

Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

When a tag is used in a patch subject (e.g. "tag: rest of message") and
it cannot be found as an alias, patman currently reports a fatal error,
unless -t is provided, in which case it reports a warning.

Experience suggest that the fatal error is not very useful. Instead,
default to reporting a warning, with -t tell patman to ignore it
altogether.

Signed-off-by: Simon Glass <sjg@chromium.org>

With the subcommands some of the documentation examples are no-longer
correct. Fix all of them, so it is consistent.

Signed-off-by: Simon Glass <sjg@chromium.org>

patman's --limit-cc option parses its argument to an integer and uses
that to trim the list of CC recipients to a particular maximum. but that
only works if the cc variable is a list, which it is not.

Signed-off-by: Bernhard Kirchen <bernhard.kirchen@mbconnectline.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

At present on large files, lz4 uses a larger block size (e.g. 256KB) than
the 64KB supported by the U-Boot decompression implementation. Also it is
optimised for maximum compression speed, producing larger output than we
would like.

Update the parameters to correct these problems.

Signed-off-by: Simon Glass <sjg@chromium.org>