This function is only used locally. Enabling -Wmissing-prototypes triggers
a warning. Mark it as static.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

The -V version parameter is missing in the optional list of parameters
in help text. Add it.

Signed-off-by: Marek Vasut <marex@denx.de>

This header was already included just above version.h,
do not include it twice.

Fixes: 3db71108575 ("crc32: Use the crc.h header for crc functions")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

Drop inclusion of crc.h in common.h and use the correct header directly
instead.

With this we can drop the conflicting definition in fw_env.h and rely on
the crc.h header, which is already included.

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

At the moment mkenvimage has two separate read paths: One to read from
a potential pipe, while dynamically increasing the buffer size, and a
second one using mmap(2), using the input file's size. This is
problematic for two reasons:
- The "pipe" path will be chosen if the input filename is missing or
  "-".  Any named, but non-regular file will use the other path, which
  typically will cause mmap() to fail:
  $ mkenvimage -s 256 -o out <(echo "foo=bar")
- There is no reason to have *two* ways of reading a file, since the
  "pipe way" will always work, even for regular files.

Fix this (and simplify the code on the way) by always using the method
of dynamically resizing the buffer. The existing distinction between
the two cases will merely be used to use the open() syscall or not.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>

It is perfectly fine for the read(2) syscall to return with less than
the requested number of bytes read (short read, see the "RETURN VALUE"
section of the man page). This typically happens with slow input
(keyboard, network) or with complex pipes.

So far mkenvimage expects the exact number of requested bytes to be
read, assuming an end-of-file condition otherwise. This wrong behaviour
can be easily shown with:
$ (echo "foo=bar"; sleep 1; echo "bar=baz") | mkenvimage -s 256 -o out -
The second line will be missing from the output.

Correct this by checking for any positive, non-zero return value.

This fixes a problem with a complex pipe in one of my scripts, where
the environment consist of two parts.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Alexander Dahl <ada@thorsis.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>

The size of 'filebuf' was not increased as more and more bytes are read
from stdin, but 'filebuf' was always reallocated to the same fix size.
This works as long as only less bytes than the initial buffer size come
in, for more input this will segfault. (It actually does, I tested
that.) So for each loop cycle the buffer size has to be increased by the
number of bytes we want to read.

Signed-off-by: Alexander Dahl <ada@thorsis.com>

On success read() returns the number of bytes read or zero for EOF. On
error -1 is returned and errno is set, so the right way to test if read
had failed is to test the return value instead of errno.

Signed-off-by: Alexander Dahl <ada@thorsis.com>

The current head revision of mkenvimage
(e72be8947e129f5ab274c0a9f235d2cc0014b2ea) will prevent you from creating
an env image from a text file that is larger than the env length specified
by the '-s' option.  That doesn't make sense given that the tool now allows
comments and blank lines.  This patch removes that limitation and allows
longer text files to be used.

I don't have time / desire at the moment to figure out "patman" and could
really care less if this is adopted up stream.  Just figured I would share
in case anybody else finds it useful enough to take time to do a proper
patch.

>From 39ff30190c2bf687861f4b4b33230f1944fb64f9 Mon Sep 17 00:00:00 2001
From: Brian McFarland <bmcfarland@rldrake.com>
Date: Thu, 12 Mar 2015 11:37:19 -0400
Subject: [PATCH] In mkenvimage, removed the check that prevented using a
 source text file larger than the output environment image.  Instead, the main
 parsing loop checks to see if the environment buffer is full, and quits if it
 is.  After the main parse loop, a second loop swallows comments and
 whitespace until either the EOF is reached or more env vars are found, in
 which case an error will be thrown.