Sphinx expects Return: and not @return to indicate a return value.

find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

With the new TOOLS_LIBCRYPTO and some other changes, it seems that we are
heading towards calling this a tools build rather than a host build,
although of course it does happen on the host.

I cannot think of anything built by the host which cannot be described as
a tool, so rename this function.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

The gzip API uses the u64 type in it, which is not available in the host
build. This makes it impossible to include the header file.

We could make this type available, but it seems unnecessary. Limiting the
compression size to that of the 'unsigned long' type seems good enough. On
32-bit machines the limit then becomes 4GB, which likely exceeds available
RAM anyway, therefore it should be sufficient. On 64-bit machines this is
effectively u64 anyway.

Update the header file and implementation to use 'ulong' instead of 'u64'.

Add a definition of u32 for the cases that seem to need exactly that
length. This should be safe enough.

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

This function should have a comment explaining what it does. Add one.

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

Add a host_build() function, so that it's possible to
check for software being build with USE_HOSTCC without
relying on preprocessor conditions. In other words

 #ifdef USE_HOSTCC
 	host_only_code();
 #endif

can be written like this instead:

 if (host_build())
 	host_only_code();

This improves code readability and test coverage and
compiler will eleminate this unreachable code.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Define this macro always so we don't need the preprocessor to check it.
Convert the users to #if instead of #ifdef.

Note that '#if MEM_SUPPORT_64BIT_DATA' does not give an error if the
macro is not define. It just assumes zero.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Stefan Roese <sr@denx.de>

This is not really a CONFIG since it is not intended to be set by boards.
Move it into the compiler header with other similar defines, and rename
it.

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

The build failure was originally reported on arm64-musl
target at https://bugs.gentoo.org/703132. Here is the amd64-musl
variant:

```
$ LANG=C make CROSS_COMPILE=x86_64-gentoo-linux-musl- tools-only_defconfig -j$(nproc)
$ LANG=C make CROSS_COMPILE=x86_64-gentoo-linux-musl- tools-all            -j$(nproc)
...
In file included from tools/env/../../env/flags.c:7,
                 from tools/env/env_flags.c:1:
include/env.h:159:1: error: unknown type name 'ulong'; did you mean 'long'?
  159 | ulong env_get_ulong(const char *name, int base, ulong default_val);
      | ^~~~~
      | long
```

Note: 'ulong' is not defined there.

On glibc 'ulong' comes from <sys/types.h>:

```c
/* Old compatibility names for C types.  */
typedef unsigned long int ulong;
```

On musl it comes from <sys/types.h> as well but from under different guards:

```c
typedef unsigned long u_long, ulong;
```

The change inlines 'ulong' define similar to 'uint' define.

Bug: https://bugs.gentoo.org/703132
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

You do not need to use the typedefs provided by compiler.

Our compilers are either IPL32 or LP64.  Hence, U-Boot can/should
always use int-ll64.h typedefs like Linux kernel, whatever the
typedefs the compiler internally uses.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

FreeBSD, like OpenBSD, uses BIG_ENDIAN, LITTLE_ENDIAN, and BYTE_ORDER,
whereas Linux and compatibles use __-prefixed names.  Define the names
the same as the OpenBSD block below it.